>
> In my experience, the single-threaded design is a little simpler to
> implement and test but lacks performance. For me the question has
> always been how much data will be traveling over time. High data rate?
> Going to need threads. Low data rate? Just plop the components on a
> form and set some event handlers.
>
This appears to be a 'chat-type' app, where one client can send data to the
server that has to be distributed to all other clients. All 'chat' apps are
a major PITA. The PITA-ness increases hugely if no operation must block,
eg. none of the writes to the the dozens of clients can block without
siezing the whole app. AFAIK, with conventional non-blocking servers, if
one client becomes ureachable during a big write, the whole app gets stuck
until the socket times out. Either that, or the call returns immdiately
with 'would block', and the data has to be queued in the socket context
until an 'onCanWrite' event comes in. This is more than plopping components
onto a form and setting event handlers - it's well on its way to becoming a
complex state-machine, with the added constraint that none of the actin
routines bust block on anything.
Rgds,
Martin
