Jonathan Lemon wrote:
>
> Also, consider the following scenario for the proposed get_event():
>
> 1. packet arrives, queues an event.
> 2. user retrieves event.
> 3. second packet arrives, queues event again.
> 4. user reads() all data.
>
> Now, next time around the loop, we get a notification for an event
> when there is no data to read. The application now must be prepared
> to handle this case (meaning no blocking read() calls can be used).
>
> Also, what happens if the user closes the socket after step 4 above?
Depends on the implementation. If the item in the queue is the
struct file (or whatever an fd indexes to), then the implementation
can only queue the fd once. This also avoids the problem with
closing sockets - close() would naturally do a list_del() or whatever
on the struct file.
At least I think it could be implemented this way...
gid
>
> The user now receives a notification for a fd which no longer exists,
> or possibly has been reused for another connection. This may or may
> not make a difference to the application, but it must be prepared to
> handle it anyway. I believe that Zack Brown ran into this problem with
> one of the webservers he was writing.
>
> > > You can find my paper at http://people.freebsd.org/~jlemon
> >
> > I'll go and read it now. :)
>
> The paper talks about some of the issues we have been discussing, as
> well as the design rationale behind kqueue. I'd be happy to answer
> any questions about the paper.
> --
> Jonathan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:17 EST