>From my experience I'd say its not, but any way: what would it take
to make HTTP::Daemon thread safe? Are there any plans to do this?
If I were to do this, is there interest?
I'm a bit new to threaded perl, but I have noticed following
obstacles in writing thread safe code for perl
* file handles can't be made "my"
* local variables can not be safely used in threaded code
(another thread can unexpectedly unlocalize your local
variable in middle of a basic block)
* behaviour of magic variables is not well defined, e.g. $_
can't be made "my" but its used by many very important
perl constructs, such as map and grep. For these constructs
there does not seem to exist alternatives. Either they
must be magically thread safe (although $_ can't be made
local?!?) or you simply can't use such constructs (which
is a shame because I love map).
So far my experience with threaded perl and HTTP::Daemon indicates
that it works mostly OK with linuxthreads (2.2.x kernel series,
glibc-2.0.x series) on uniprocessor boxes. The same scripts
on SMP boxes break in mysterious, but certain ways, hence
HTTP::Daemon is unusable with SMP and threads.
--Sampo
S/MIME Cryptographic Signature
