Re: Comm API notes

On ons, 2008-09-10 at 11:33 -0600, Alex Rousskov wrote:

> Since all notifications are asynchronous, it is possible for a read
> or write notification that was scheduled before comm_close was
> called to arrive at its destination after comm_close was called.
> Such notification will arrive with COMM_ERR_CLOSING flag even though
> that flag was not set at the time of the I/O (and the I/O may have
> been successful). This behavior may change.

Ugh...

This will be a bit of a nightmare.

Is there really any callback which uses COMM_ERR_CLOSING? I remember
doing an audit of this the last time we discussed this, but don't quite
remember if I found any...

What I do know is that most callbacks looks for COMM_ERR_CLOSING and
immediately return without any action if set.. If you need close
notification you install a close handler.

> COMM_ERR_CLOSING interface will be removed. The read, write, and
> accept notifications will not be scheduled after comm_close is
> called. New user code should register close handlers instead.

+1 on that.

> When COMM_ERR_CLOSING interface is removed, pending notifications
> (if any) will be canceled after comm_close is called. However, the
> cancellation may be removed later if Comm is modified to provide safe
> access to closing descriptors and their fragile state. New user code
> should continue to assume that it is safe to access Comm in a read,
> write, and accept handlers.

Here is a slight design topic to discuss..

Consider

bunch of comm_write queueing stuff on the fd.

comm_close to signal EOF.

Allowing batching of these is great for network performance, and if done
so then there need to be notification on the success/failure of the
writes..

One could also do this by splitting comm_close in comm_eof (shutdown())
and then comm_close after getting the success/failure notification(s),
but that's a bit too much I think.

I guess the close handler can be used for this, if extended to include a
"closed successfully" or "closed with I/O error" indication.

> The comm_close API will be split into "stop I/O" and "kill me" APIs.
> New user code should not use comm_close for the purpose of ending a
> job (and should not assume it does). In most cases, the job has more
> tasks to do even if the descriptor is closed. AsyncJob API provides
> job-ending tools.

Not sure I get this..

> Raw socket descriptors may be replaced with unique IDs or small
> objects that help detect stale descriptor/socket usage bugs and
> encapsulate access to socket-specific information. New user code
> should treat descriptor integers as opaque objects.

+1

Also needed to port Squid to native Windows I/O. There is no
filedescriptors in win32, only objects... The socket filedescriptors
(and their related file filedescriptors) is a wrapper layer and what
limits SquidNT to 2048 filedescriptors...

Regards
Henrik
Received on Wed Sep 10 2008 - 20:58:26 MDT