Re: [bug-mailutils] POP3 code changes

[Alain Magloire]

> 
> On Mon, Dec 23, 2002 at 06:18:10PM -0500, Alain Magloire wrote:
> > > 
> > > > I missed something along the way here - Why would we drop support for
> > > > thread-safety?
> > > 
> > > Really, why would we? Another question is, it is not proven the
> 
> > It is hard to get right and the overall complexity could not be worth.
> > Lots of mail applications non-threaded.
> 
> I would argue then for at least coarse locking.  Both the MUAs I've used
> recently (evolution and mozilla) are very threaded.  I think it would be
> fine to have a global lock that we called on entering the code, and an
> unlock on exit.
> 
> > > libmailbox is thread-safe. We do have provisions for cancellation
> > > points, but have we tested this? I mean have anybody tried to
> > > use libmailutils in a real multithreaded application?
> 
> > Yes, it was tested on an application call "phemail" (it was rename,...
> > marketing did not like the sound of it, the developers tried PMS ...
> > (Photon Mail System) but for some reason PMS, did not survive either).
> 
> ROFL!
> 
> > complexity is an exponential for the number of bugs, the size and
> > the maintainance nightmare ... Should be able to make some sort
> > of mathematic equations with this.
> 
> Would a very simple locking mechanism like I propose be good enough?

That's not that simple, if you use global lock, you are no longer
reentrant or simply can not call another function, you will self-deadlock.
Also for cancellation points, you have to make sure that you
release the lock, for example read() is a cancellation point and you
will have to make sure that the thread releases the lock.

Fine grain locking with read/write monitors is probably better.
Doing a big lock that serialize the entire library loose the
advantage of having threads in the first place.

You do have a point though, if more and more applications are threaded
it would be a good thing to do/continue/fix, then the question now is,
if threads are popular why bother with the non-blocking complexity 8-)?

Also, I would propose to stick with Pthreads API and not bother
with the other zillions of threads API.