Re: [Evolution-hackers] Let the porting begin

[Jeffrey Stedfast <fejj novell com>]

On Fri, 2007-10-26 at 03:25 +0200, Philip Van Hoof wrote:
> On Wed, 2007-10-24 at 11:58 -0400, Jeffrey Stedfast wrote:
> > I took a look at the IDLE implementation last night and felt it went
> > about it the wrong way.
> 
> Yes, you are right. I think the right fix is to create a new API called
> camel_tcp_stream_wait that works like this:
> 
> 
> int bytes = camel_tcp_stream_wait (tcp_stream, stop_fd,
> 	 store->idle_sleep, line_buffer, 1023);
[snip]

I was thinking more along the lines of making the idle_loop use
PRPoll()/poll() itself - it already has to figure out what type of fd to
create for the cancel_idle_fd anyway.

> 
> Afaics It's not true that you don't need to change any API:
> 
> The camel_stream_read() will block until all n bytes are read.

no it doesn't. it returns as soon as any number of bytes are read or an
error occurs.

>  This is
> something you don't know during IDLE (how many bytes you can expect to
> receive), and on top of that you want to continue immediately after
> select returns, not keep retrying until you have n bytes (to simulate a
> blocking read).

sure, but that's why you poll yourself. once the socket has data, /then/
you call camel_stream_read() on it.

>  You also want a dedicated stop fildescriptor, not the
> standard cancel_fd as then any cancel will interfere with this (while
> you want strict control over this to let other threads start and stop
> IDLE).

right, but if you add a CamelStream API, then you have to add 1 for unix
fds and 1 for PRFileDesc

plus it keeps the code simpler (keeps all read() logic in the
camel_stream_read() implementations rather than duplicating it).


This actually brings me to another thought I've had for a few years now
but haven't bothered pushing for it... but it might be best if all of
the sockets used PRFileDesc rather than unix fd for raw sockets and
PRFileDesc for SSL sockets. If this is done, I think it'd be possible to
get rid of CamelTcpStreamRaw and move the implementation into
CamelTcpStream and make CamelTcpStreamSSL a simple subclass of
CamelTcpStream, replacing the CamelTcpStream's PRFileDesc with an
SSL-wrapped fd as appropriate and calling parent_class->read/write/etc
instead of implementing them all itself /again/.


Jeff