Hi Frank On Wed, 2008-06-18 at 15:30 +0200, Frank Schönheit - Sun Microsystems Germany wrote:
> What I would not like to do is implementing the same thing in two > modules. :-) yes > What I wanted to say with my comment about CWS dba30d is that in this > CWS, I re-factored the handling of the value bindings, so that the > base > class (OBoundComponent) does all the administrative stuff, and just > calls some virtual methods which need to be implemented by derived > classes. The set of those virtual methods could perhaps be a good > starting point for designing IBindableValue. I will try to digest the IBindableValue idea later ( my gut feeling to to stick with the simpler model substitution approach ) > > > Also perhaps I shouldn't give up on the orig idea of just > substituting > > the Models ( it would seem to be the easier solution ), but for that > I > > must have a look at these hangs and see why this is happening. > > I agree that model substitution is most probably significantly easier. > Though the other approach is "nicer" with respect to its architecture, > it doesn't bring much other gain. yup, unfortunately also I am a time constrained ( like everyone I am sure ) so another reason to try at least substitution > > For the deadlocks: Again, let me recommend you the CWS dba30d > (respectively a master milestone where it is integrated): The > reasoning > for the aforementioned re-factoring was that Calc's cell binding > implementations insists on locking the solar mutex (indirectly, in > reality the Cell implementations do), which is absolutely deadly when > called from a non-main thread with another mutex locked. So, I > overhauled the OBoundComponent implementation so that every call into > the external binding is guaranteed to have no own mutex locked - > perhaps > this helps in your scenario, too. yes it might :-) meanwhile, yesterday I had some time to try and look at the hang and it turns out to be the classic t1: acquires Lock1 then tries to acquire Lock2 ( meanwhile t2: has acquired Lock2 and tries to acquire Lock1 ( and deadlock ) t1 - procession of ItemStateChange at the form control t2 - a mouse move for which an event binding exists Lock2 is is the solar mutex, Lock1 is imo an unnecessary lock grabbed by the dialog event handling code. Maybe dba30d will help here ( certainly removing the acquire of Lock1 moves the problems out of the way ) When I get a chance I will extract the > > Ciao > Frank > > PS: I'm on vacation starting tomorrow, 'til end of June, so don't > expect > any quick answers the next 10 days ... enjoy the holidays, since model substitution *seems* the route of least resistance I will try and continue that way. In anycase even if it turns out that it ultimately fails and some IBindableValue foo becomes necessary at least all of the rest of the supporting changes will still be valid ( properties, persistence etc. ) So I think I have more than enough information to continue. Thanks again for the help/info & advice Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
