Re: [ftpbench] Wrapper for poll()
- On Fri, 18 Aug 2000, Zach Brown wrote:
> you're on :) I honestly don't care what the result of thisYeah, okay. Next time I'm in the U.S. (or the next time you're in
> 'experiment' would be, I just want to see either of us try and drink
> that much tequila :)
Amsterdam) we can hook up. We'll bring a laptop to the bar. ;)
> > I guess I just don't get this. Why would a signal mechanism be any moreYeah okay. I guess this could seriously affect you if you had a lot of
> > efficient than a poll() mechanism at I/O? Is the idea to establish an
> > I/O buffer shared by the user process and kernel, and use that to avoid
> > the extraneous copy on read or write operations (this would be nice)?
> It gives you light weight event notification. each poll() call you're
> forced to tell the kernel about what you're interested in. That's
> expensive. With the signal stuff you register a process that should
> receive a signal when a descriptor has work to do. You then get a queue
> of these signals for lots of fds..
connections waiting a long time for data to show up - as is the case in an
SQL server. I can easily imagine the worst case: a corporation with
50,000 SQL connections open, with only 50 performing a query at any given
time, which still maxes out disk and network I/O for long periods of time.
(Of course, these folks should probably consider a different architecture,
but they probably weren't expecting this behavior when the salesmen told
them how great their centralized database would be.)