I'm inclined to buy that, because a) so far no other project has reported any issues b) the pre-nio code ran just fine on nptl and it used far more threads c) all deadlocks happen in roughly the same area of the code d) we're locking too much at certain places e) and last but not least, performance on nptl systems such as redhat9 and gentoo is significantly better when nptl is enabled. And nptl will be enabled even on de^H^H<include your favorite conservative distribution> sooner or later.
All in all, I think locking really needs to be reviewed by more people. A diagram of some sort would be very helpful, if someone has access to automatic UML or dependency graph generating software, it would be great.
=============
Some specific information follows, if you're not familiar with the code it won't make much sense:
I removed the locking on sendlock and sentMessages in the CH.jobDonePartial and CH.jobDone where we notify all messages on the list that one of them failed. The lists are synchronized so that locking really wasn't necessary.
There is still a huge lock on sentMessage where the coalescing happens; it includes initial copying from sendingQueue to sentMessages, coalescing and sending off to wsl. I haven't touched it, but imho we need the lock on sentMessages only during the coalescing part. If the entire sequence needs locking, I'd rather do it on sendLock or another object. The first part is safe as both lists are synchronized and the loops will respect the packet size limit eve n if new elements are added to the sendingQueue list. The third part is, well, pretty risky as it involves lots of locking in wsl and lots of exceptions are thrown whose catch statements are scattered around several levels of locking.
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
