RE: /dev/yapoll : Re: [PATCH] /dev/epoll update ...

[Davide Libenzi <davidel@xmailserver.org>]

On 21-Sep-2001 Christopher K. St. John wrote:
>  To save further pointless argument, I'm calling the
> experiment "/dev/yapoll". 
> 
>  Specifically, I've added code to return the initial
> state of the fd's as they are added to the interest
> list. It seems to work ok so far, but I'll be doing
> some benchmarking this weekend. I will post a patch
> if no problems turn up.

By reporting the initial state of the connection will make
/dev/epoll to be a hybrid interface and looks pretty crappy to me.
You'll be able, eventually, to skip only the first system call anyway.
You still won't be able to use an interface like :

        if (ioctl(DATA_READY))
                read();

Coz if 2000 bytes arrives on the terminal and you read only 1000 bytes
you won't receive another POLLIN event and you'll get stuck in the ioctl().
You can avoid this in two ways :

1) test ( w/ or w/o hints ) the readyness of the terminal, that means /dev/poll

2) add inside the network code functions that are going to maintain the state
        of the connections directly by writing your own fd-state token.
        Tha means
        1) when the data is exhausted it clears the data-ready bit
        2 ) when the tx buffer is full it clears the terminal-ready bit

But, again, you're going to have a state reporting interface vs an event reporting
one like /dev/epoll




- Davide