Dean Gaudet wrote:
> Dan Kegel wrote:
> > Dean Gaudet wrote:
> > > what if there were:
> > > accept2(int s_listen, struct sockaddr *, int *addrlen, int s_client);
> > > where s_client is a socket created by socket() with its options all set up
> > > as desired by the application? that way the app can do the F_SETSIG/etc.
> > > before it is attached to the network.
> >
> > Alternately, accept2() might create a new socket but copy all socket
> > settings and options from s_client. Then the socket returned from accept2()
> > would be an instance of the class defined by s_client, as it were.
>
> i thought about it more and it doesn't make sense -- it doesn't save any
> syscalls really... in the current model you have to do an extra read() to
> check if you missed an event. with accept2() you have to do an extra
> socket(), so it works out the same.
If accept2() behaves as I suggested, it does the call to socket() for you,
so it would indeed save a syscall. (And you only need to do the F_SETSIG,
etc. on the initial prototype s_client once; after that, accept2() would
just copy the settings.) But that's not why I like it so much; read on.
> so in the unlikely event that the last write() hit the send buffer
> edge you might have a ghost write event in the queue before the shutdown
> happens. and in the uncommon event that the read() doesn't return
> EOF before the timeout occurs *and* the client sends data at just
> the wrong moment before the close() then you might end up with a
> ghost read event.
>
> and so you might pay an extra syscall or two *occasionally* on a new
> socket for events meant for an older socket... but... i guess i'm
> just unconvinced this is a performance problem worth making complex
> kernel changes for :)
Ghost read events can confuse user code and make it think it's hit
the end of file. Translating your example
while (read(s) > 0) {};
close(s);
to event-driven pseudocode yields
do {
sigtimedwait(...)
...
if (event is 'fd now readable') {
if (read(fd) == 0) {
terminate connection, other end closed
}
}
A ghost read event could cause this code to terminate a new connection prematurely.
This isn't a performance problem, it's a reliability problem.
Or at least a complexity problem; I'm sure there are workarounds for this,
but I don't know how simple they are.
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:29 EST