Feb 15, 2011 at 10:21 PM

This may seem like a strange idea given that there don't seem to be many contributors, but have you considered moving to a DVCS like git?  Such as on github?  It would make the barrier to contribution a bit lower.

I'm going to try the trunk against our suite of unit tests and see how it goes.  I'm looking to eliminate that deadlock error, and if I have to add a bunch of debugging code to print out transformations, I'd rather contribute that back.  I figured it would make sense to do the changes against the trunk.

Feb 16, 2011 at 12:21 AM

Well, maybe you already knew this would happen, but a great many tests failed.  Are there significant blocks of missing code, or is it just that the new code base is untested?  Basically I'm asking if it would be fruitful to try and find bugs, or if it's more a matter of implementing some sort of predefined plan to progress the new version.

Feb 16, 2011 at 1:52 PM

No, that is not right. The unit tests should not fail. Make sure you are doing a Debug build and not a Parallel build version.

If the tests still fail is there any pattern in the failures? Like all Concurrency tests or Correctnes tests?

Feb 16, 2011 at 7:45 PM

Looks like a Debug build with your default project file.  I'll do some poking around to come up with a test case.

Feb 18, 2011 at 10:14 PM

It seems that some files were missing from the unittest project. For some reason this happens sometimes. I Added them to source control.

Feb 18, 2011 at 10:34 PM

Just got a latest version of the trunk on a different machine. It compiles and the unittests succeed. Hope it does the same for you.

Feb 18, 2011 at 11:05 PM

I was referring to our internal unit tests, not to the ones included with Obtics anyways.

Feb 22, 2011 at 5:24 AM

I tracked down one of the problems and submitted a bug report for it.  Hopefully this is helpful.

Feb 24, 2011 at 11:29 AM

Thanks for submitting this and it is an issue that reoccurs regularly. This reason that it occurs is obscure but is in fact by design and can be explained.

First: Transformation pipelines do not build up the event machinery before the first client registers for events and break down this machinery immediately when the last client unregisters. This is because the whole chain of event handlers from source to client will keep the transformation pipeline allive and in memory. This is nice when clients are registerd but must not happen unneeded.

Second: Value transformations will send new change notifications only after some client has read it's latest value. So when they send a change notification but nobody seems interested in the actual value (by getting the Value property) they will not send any subsequent change notifications. This is a nice optimization that reduces the number of change notifications sent and is an escape hatch for the infamous X problem. That is a problem where say you have 3 transformations (A, B and C) chained together, where A depends twice on its source, B depends twice on A and C twice on B. Then a change in the source would cause 2 events to arrive at A. This would cause 2 x 2 = 4 events to arrive at B. That would cause 4 x 2 = 8 events to arrive at C. The number of events would grow exponentialy. The escape is that if the eventual client does not get the value for C immediately when an event arrives ( for example by using .Async() ). Then one event wil travel from Source -> A -> B -> C and A, B and C will block any further events. Only later, when the client gets the new value, new events will be passed through.

First and Second combined means that if you first get the Value of a transformation pipeline and second register for change notifications you may not receive any change notifications.

And last in a multithreaded environment the procedure of first getting the value and second registering for changes would be just plain wrong. In that case you would miss all the significant change events that might occur between the moment of getting the value and registering for changes.

So: first register for change notifications and second get the value.



Feb 24, 2011 at 4:14 PM

Registering first and getting the value second is problematic for us.   Registering first causes the get method on properties to fire, where we have lazy logic to hook up additional change notification and such.  This causes deadlocks.  We avoided this by reading from the properties first and then starting to monitor for changes later.

It sounds like a viable work-around would be to get the value, hook up for property changed, and then get the value again.  I do recall dealing with this problem previously, but didn't realize that we had introduced it inadvertently again.  Thanks for your thoughts on this one... it's not the first time it's bitten us. :(

Feb 24, 2011 at 7:12 PM

In that case you might be interested in some experimental code I posted in this thread http://obtics.codeplex.com/discussions/236924

It is actually meant to improve startup time. It offers an alternative CompileObservable method named CompileDelayedObservable. The result will use the original, fast expression to calculate the value initially (even when clients register for events) and only later, asynchronously, will build up the complex transformation pipeline with all event registrations.