[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: TUX and a Java servlet engine

Michael K. Johnson wrote:

simultaneously connected clients is in non-blocking I/O. I'm assuming TUX uses /dev/poll or provides similar functionality .. if it doesn't,

No, it doesn't use polling *at all*. It queues rich protocol events.

OK, so it queues events. How does it wait on a socket, or a group of sockets?
Just because I said /dev/poll doesn't mean I meant TUX spinlocks waiting
for data on a socket:-)

TUX is probably the wrong approach because from all the data I've seen /dev/poll is the only thing that works (vs select() or poll() above 500 simultaneous connections, which means you are better off with Matt Welsh's Java (using Native methods) NBIO library which uses /dev/poll.

TUX deals with events something like this:
 o  Simple, in-cache events are served without scheduling


o Simple, not-yet-in-cache events are handled by a cachemiss thread o Other events are pushed off to user space and handled as events This is similar to RT signals in some ways, except that the events carry their data and can't get lost from overflow like RT signals can because there is a protocol engine underneath.

TUX has no use for /dev/poll because it is far more efficient.

That's what I like to hear! However, I still don't know why as you haven't said what you use in place of /dev/poll.

This is why the TUX API is so different from everything else out there.

It sounds like it's just another non-blocking system where the messages are HTTP messages instead of plain bytes. No?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []