On Sun, 2003-01-05 at 13:22, Mika Liljeberg wrote: > Hi Jeff, > > You'll note that EMsgPort has its own .lock member
yes, I know :-) > , which is acquired by > e_msgport_put(), e_msgport_get(), e_msgport_wait() and all other > routines before accessing or modifying the message port data. yea... > To me this > a pretty strong indication that this is a mailbox that is accessed by > multiple threads. Looks like a pretty standard client-server pattern, > where the server thread is sitting on top of a mailbox and dispatching > service requests from client threads. > > I think EThread.lock is there just to protect the EThread member > variables. of which, server_port is one of them ;-) What I'm saying is that EThread.server_port's queue is not modified outside of a EThread.mutex and so it is all safe. If that wasn't the case, I would agree with you - then there would be a poblem, but as far as I can tell, EThread.mutex is always in a locked state when EThread.serverport.queue is modified in any way. if you can find evidence to the contrary, please point it out. Jeff > I don't know the code very well, so I could be completely off > the base, though. > > Cheers, > > MikaL > > > On Sun, 2003-01-05 at 20:03, Jeffrey Stedfast wrote: > > > As you can see, there are two calls to e_dlist_length() to find out the > > > message queue length without locking it first. e_dlist_length() iterates > > > the whole message queue, which might be modified simultaneously by > > > another thread. > > > > except that it can't be modified by another thread because a few lines > > above the code you pasted, there is a: > > > > pthread_mutex_lock (&e->mutex); > > > > Note that (assuming I am reading the code correctly, anyway) the EThread > > (e) *owns* the EMsgPort (e->server_port). This means that so long as we > > don't access the EThread's EMsgPort directly (which we can't, note that > > EThread is a private structure) or without first locking e->mutex, there > > can be no "thread locking problems". > > > > Simply put: so long as e->mutex is locked, accessing > > e->server_port->queue is safe. There is no need to lock > > e->server_port->lock. > > > > So, this means that the only way problems could arise is if we modify > > e->server_port->queue outside of a e->mutex lock. I scanned the code and > > could not find evidence that this could occur. > > > > I think that the corruption to this list may be more likely to just be > > random memory corruption than a bug in the e-msgport.c code, but I'll > > wait to see what Michael Zucchi says (he's the one that wrote this > > code). > > > > Jeff > > _______________________________________________ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
