Luigi Rizzo wrote: > I have an ugly fix, below - store the relevant values from > module_list in a static variable not subject to constructors, > and restore module_list from that variable near the beginning > of load_modules(). > > However i don't like it too much, and furthermore I am afraid that > the same problem - unspecified order in the execution of > constructors - may appear also in other parts of the code.
This is definitely a nasty problem. My first thought on a more complete fix for this is to remove the usage of constructors to initialize linked lists. The linked list constructors do: 1) Set head/tail to NULL 2) Initialize the lock #1 is trivial to set statically. #2 is more of a problem. On Solaris and *BSD, we currently don't have a way to initialize locks statically. Assuming this is still not possible, one thing we could do is initialize them the first time they get used. In fact, there used to be some code that did that. It is still in lock.h of Asterisk 1.2. Search for "FIRST_USE". I'm thinking that we should look at changing static lock initialization to work that way. This would also close bug #11116, which is about this exact issue: dependencies between the order of constructor execution for initializing mutexes ... http://bugs.digium.com/view.php?id=11116 > Anyways, if you think it is ok to commit this one i will do > as a temporary bandaid. Yeah, if it fixes it for you, then that's ok for now. If you don't mind, make sure the bandaid works on linux, as well. But, I'd really like to come up with a more complete solution. -- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc. _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
