On Mon, Nov 25, 2002 at 08:36:59PM -0800, Manoj Kasichainula wrote: > On Mon, Nov 25, 2002 at 07:12:43AM -0800, Brian Pane wrote: > > The real reason I don't like the mutex around the poll is that > > it would add too much latency if we had to wait for the current > > poll to complete before adding a new descriptor. When the > > Listener accepts a new connection, or a Request Processor creates > > a new response brigade, it needs to get the corresponding socket > > added to the pollset immediately, which really requires interrupting > > the current poll. > > Hmmm. That's a problem that needs solving even without the mutex though > (and it affects the design I proposed yesterday as well). When you're > adding a new fd to the reader or writer, you have to write to a pipe or > send a signal. The mutex shouldn't affect that. > > BTW, ISTR Ryan commenting a while back that cross-thread signalling > isn't reliable, and it scares me in general, so I'd lean towards the > pipe. > > I'm pondering what else could be done about this; having to muck with a > pipe doesn't feel like the right thing to do.
Why not? Add a descriptor (pipe, socket, whatever) to the pollset and use it to indicate the need to generate a new pollset. The thread that sends info down this descriptor could be programmed to wait a short amount of time between sending triggers, so as not to cause the select() to return too, too often, but short enough not to delay the handling of new connections too long. And the select()er thread would need to add a quick step to check for this special descriptor instead of treating them all as external requests. It would also need to somehow signal the other thread each time select() returned so that waiting descriptors could be added immediately. Or am I smoking what Manoj is smoking? -Glenn
