[lkml]   [2001]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: /dev/yapoll : Re: [PATCH] /dev/epoll update ...

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))

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.031 / U:3.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site