Re: [bug-mailutils] POP3 code changes

[Alain Magloire]

> 
> > 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.


> 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).


Threading and non-blocking issues for POP3 in particular were
tested.  Some problems with IMAP4 and non-blocking, not all the API could
manage to "restart" at the right place, when EAGAIN was return.


The gist, is how much complexity you want to put in the library, complexity
comes with a heavy maintaince/bug cost.

A simple protocol like POP3 can double/triple the code complexity
if you want to make it {async,thread,cancel}-safe.  And now think
about complex protocol like IMAP4 to be non-blocking, thread-safe,
cancel-safe ... ouch!

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.