bert hubert wrote:
> On Mon, Oct 28, 2002 at 11:14:19AM -0800, Hanna Linder wrote:
>
>
>> The results of our testing show not only does the system call
>>interface to epoll perform as well as the /dev interface but also that epoll
>>is many times better than standard poll. No other implementations of poll
>
>
> Hanna,
>
> Sure that this works? The following trivial program doesn't work on stdinput
> when I'd expect it to. It just waits until the timeout passes end then
> returns 0. It also does not work on a file, which is to be expected,
> although 'select' returns with an immediate availability of data on a file
> according to SuS.
I'm checking this and will let you know.
> Furthermore, there is some const weirdness going on, the ephttpd server has
> a different second argument to sys_epoll_wait.
You're right. The ephttpd server on Davide's page needs to add a cast
(struct pollfd const **) to the second arg passed to sys_epoll_wait.
The version of dphttpd used to generate the results had that fix in it.
-- Shailabh
On Mon, 28 Oct 2002, Shailabh Nagar wrote:
> > Furthermore, there is some const weirdness going on, the ephttpd server has
> > a different second argument to sys_epoll_wait.
>
> You're right. The ephttpd server on Davide's page needs to add a cast
> (struct pollfd const **) to the second arg passed to sys_epoll_wait.
> The version of dphttpd used to generate the results had that fix in it.
It's true, I gave IBM the ephttpd that was using the first draft of the
interface that had a 'struct pollfd **' parameter. Later I changed the
implementation to 'struct pollfd const **' because I also changed the way
the mmap prot are used ( now mmap()ed PROT_READ only ).
- Davide