Nonblocking TCP transport
JXTA-C implementation used to use a lot of threads, that really bothers me. I am not against writing multi-thread applications or saying threads are bad, but thread is for doing things in parallel, not to create bureaucracy. Also thread is a system resource that I don't like to waste.
By bureaucracy I mean a common pattern I observed: Having objects create threads for processing requests. A task can then be handed over from a thread to another because of those object boundaries. This is an easy way to do things asynchronously, it also gives an illusion that the code is now a multi-threaded and the performance would be better. Unfortunately, this is usually not a good way to partition a task.
A pattern in JXTA-C was
By bureaucracy I mean a common pattern I observed: Having objects create threads for processing requests. A task can then be handed over from a thread to another because of those object boundaries. This is an easy way to do things asynchronously, it also gives an illusion that the code is now a multi-threaded and the performance would be better. Unfortunately, this is usually not a good way to partition a task.
A pattern in JXTA-C was
- Each connection creates a thread to read in messages.
- The thread hands the message to a listener registered for that message based on the destination address of that message. It is not unusual a message can be enveloped to a different destination, so this can be a multiple hand over between listeners.
For those who are not familiar with JXTA, a listener is basically a queue for invoking a function, which can have one or more threads to handle requests on demand. In most cases, a message only needs a very short attention to process. But it has to go through threads waiting for its turn.
Situation has being improved in JXTA-C, callbacks has being replacing listeners. Thread pool is used when asynchronous or parallelism is really needed. And with the upcoming release, non-blocking I/O is used for TCP transport implementation.
With that, the model now becomes:
- One thread is monitoring a set of connections, reading all data from the wire.
- An idle thread(or a new thread could be created) from the thread pool will pick up the connection, deal with the data from parsing until finish its processing.
- The number of threads is now limited and manageable.
- Hand over between threads due to protocol stack is eliminated.
