Re: [Evolution-hackers] Unexepected blocking reads in Camel

[Philip Van Hoof <spam pvanhoof be>]

On Mon, 2007-07-02 at 12:53 -0600, Veerapuram Varadhan wrote:
> On Mon, 2007-07-02 at 20:40 +0200, Philip Van Hoof wrote:

> > I'm not sure but it looks like if any Camel API call that causes a read
> > or a write that isn't wrapped by a CamelOperation, does a blocking read
> > or write that don't respect the timeouts.
> > 
> > I created a patch for camel-lite that does the (what I think is)
> > expected behaviour.
> > 
> IIRC, Camel calls are blocking and they are not supposed to be called in
> main thread - First lesson in Camel.  So, it is the expected behavior of
> Camel and Yes, if you have CamelOperation specified, they are
> cancellable.

It's not the fact that they are blocking that disturbs me, what is
unexpected, I think, is the fact that the IO_TIMEOUT is only respected
in case of cancel_fd being available (in case the operation is wrapped
by a CamelOperation).

In the other case, the IO_TIMEOUT isn't respected and therefore it's
possible for a thread to for ever block and wait (for example in case
the connection with the IMAP server unexpectedly disappears).

At least that is what I observed, and what the patch fixes

ps. The patch doesn't make the read and writes non-blocking, as all of
the non blocked reads and writes are being looped until what we wanted
to read, has been read or in case the IO_TIMEOUT occurs (just like when
the cancel_fd is available, only without the cancel_fd in FD_SET).


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog