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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
