[IRC and polling]
> In this case, it's a deliberate design issue.  It's certainly open for
> debate, but let me explain the reasoning.
> 
> First, using a blocking interface means adding a thread, and adding a
> thread add a lot of complexity.  This includes design work (where do the
> locks go?), complexity (implementing and using the locks), and added
> difficulty in testing  (let's run this code a million more times and try
> to make the bug appear again).  IMNSHO, many programmers severely
> underistemate what they are getting into with threads.  To contrast, the
> added complexity for polling is something like "how does my polling
> routine get invoked"; once that is worked out, the focus is on the
> function of the system.

I don't really think I agree with this. These kinds of operations are by
their very nature "multi tasking". I/O *should* be processed behind the
scenes IMO. And since the focal point of IPC is very clearly definable,
complexity isn't much of an issue. There is the queue out outgoing messages
that is shared, and there is the incoming message dispatching. Protecting
access to the output queue is trivial. For incoming messages, there's a
design issue of wheather to process messages in a separate event process or
let the calling code provide the process (or something else entirely).

But it's not a major block in the road IMO. For my Java IRC implementation
I opted to use an event dispatching thread to handle events in a listener
pattern fashion because I thought it was the obvious choice. It never even
occurred to me to use some kind of polling API :)

Maybe I'm in the minority. But I've never really had a problem with
multithreading; as far as I can recall I've never ran into a deadlock
bug for example. IMO the advantages by far outweight the disadvantages.

> Second, there are cases where polling doesn't have the ills that are
> usually ascribed to it.  In particular, polling works well when failed
> polls are cheap, and where polls can happen infrequently.  If a problem
> meets both of these criterea, then polling will work fine.  CPU usage
> will not be abnormally high, and responsiveness will be good.  IRC meets
> both criteria, while HTTP serving probably does not. 

This might be acceptable in practice. I'm a purist though; I don't like
polling as a matter of principle unless there's a *really* good reason for it
(such as implementing a progress bar when you don't want to trigger an update
after each I/O operation).

At the moment I have Squeak running an IRC bot on a server. It constantly
hogs about 0.5-2% of the CPU - probably because I'm invoking processIO four
times per second.

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0x5584BD98 or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey at scode.infidyne.com
E-Mail: peter.schuller at infidyne.com Web: http://scode.infidyne.com