Re: kqueue microbenchmark results

2000-10-27 Thread Alfred Perlstein
ed from kevent are for the new fd 5. > > (I suspect it helps that kevent() is both the only way to > bind events and the only way to pick them up; makes it harder > for one thread to sneak a new fd into the event list without > the thread calling kevent() noticing.) Yes, that's ho

Re: kqueue microbenchmark results

2000-10-27 Thread Alfred Perlstein
* Jamie Lokier <[EMAIL PROTECTED]> [001027 08:21] wrote: > Alfred Perlstein wrote: > > > If a programmer does not ever wish to block under any circumstances, it's > > > his obligation to communicate this desire to the implementation. Otherwise, > > > t

Re: kqueue microbenchmark results

2000-10-26 Thread Alfred Perlstein
hread case, this would be a bug; if one thread closes > > the descriptor, the other thread is going to get an EBADF when it goes > > to perform the read. > > Another thread may already have reused the fd This is another example of an application threading problem. -- -Alfred

Re: kqueue microbenchmark results

2000-10-26 Thread Alfred Perlstein
ure we'd be forced to adopt it, but if you make kqueue generate info an application won't care about I don't think that would be taken back. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." - To uns

Re: kqueue microbenchmark results

2000-10-25 Thread Alfred Perlstein
mply that it is one hell of a bug to block, returning an error would be acceptable, but surely not blocking. I know manpages are a poor source for references but you're the one putting up a big fight for blocking behavior from poll, perhaps you can point out a standard that contradicts the m