Re: commloops revisited

tor 2006-05-25 klockan 08:43 +0800 skrev Adrian Chadd:

> What one really wants to avoid doing is scanning each FD each time the comm
> select/poll/epoll routine is called; which I believe your code was intended
> to do. Instead perhaps you may wish to modify the SSL code to reschedule
> for another read/write if it detects something is needed. Maybe a hack is
> doable for the epoll() stuff but it'd be just a hack.

The pending stuff is not about scanning the FD arrays, it is about
separating the read/write handlers from actual events required.

SSL is different in that our I/O interface is to the SSL, not the
socket. As result a SSL_read may require either

 - a read I/O (more data needed from the network)
 - no I/O at all (data already sitting internally in the SSL library)
 - a write I/O (SSL renegotiation with the client)
 
and similarily for SSL_write and the other SSL operations.

and this needs to fit into the event loop somehow...

So it the comm code has changed to simply provide two I/O callbacks,
each of which either is

  a) Waiting for read
  b) Waiting for write
  c) Or should be called immediately

for historical and practical reasons one is called read, the other
write. The difference is in their default event unless told otherwise.

Now, if the Squid-2 code was sane with an actual network I/O layer this
shouldn't be too problematic to layer properly, but it is not and the
SSL functions execute many layers down on the side, quite separate from
commSetSelect(). So instead of having the type of event required sent in
commSetSelect() it signals this via the pending flags.. Doable thanks to
the semantic read/write split.

> Reading this code makes me believe the SSL support code should really be
> abstracted out a little further: ie, the SSL support code handles scheduling
> IO as well as handling read/write. I don't have the time to do this until
> mid-june, which means missing your release date somewhat.

Agreed.

But it's a bit too much rework of the internals to match the 2.6
release. This not only touches the comm loop, but pretty much every
single protocol module.

This should be done in Squid-3. In Squid-2 the goal is just to make it
work, not be pretty.

Regards
Henrik