Threading and Penn, part 2

Earlier I mentioned some of the difficulties with making a multi-threaded mush (Read it here.)

One of the realistic options I suggested then was doing the hostname lookups in threads instead of a separate process. Using the standard library functions for looking up a hostname associated with a given IP address can be slow, and nothing else can happen in a particular thread of execution until it finishes. When it's done in a different process (Or processes, as is the current situation -- each lookup happens in its own short-lived process) communicated asynchronously with the main mush one, this is no big deal. When it's happening in a separate thread of the mush process, no big deal.

Except it is.

The getnameinfo(3) function, which Penn uses, will, in many implementations, internally use gethostbyaddr(3), which returns a statically allocated block of data. This means that only one thread at a time can use it. This isn't all bad; it just means that only one lookup can be done at a time, instead of multiple simultaneous ones. That is how the hostname lookup slave process used to work until recently.

There are async lookup libraries intended to be used with a select(2) based event loop; problem is the one I know about is GPL, which is incompatible with the Artistic License v1 used by Penn. Also I'm hoping to move away from select() in favor of kqueue (BSDs), epoll (Linux), and poll (Everything else, except probably poor retarded Windows). Still mulling doing it myself or requiring libevent.

Conclusion: Threaded programming using the pthreads/C model is hard. You really need a model like the one erlang uses, with threads not sharing memory, only passing messages back and forth, to avoid many subtle bugs and problems. And guess what? Using a seperate process does that.