[REBOL] Re: Multithreading with Rebol
From: greggirwin::mindspring::com at: 14-Oct-2003 18:35
Hi Brian,
BP> I want to set up (say) a Rugby server, which will accept client
BP> connections and process them. I'd like each connection to be handled in
BP> its own thread (let's keep it simple and leave thread pools, resource
BP> utilization and the like out of this) as I need each client's response
BP> to be in reasonable time (pretend the processing involves I/O or
BP> something). I'm kinda astonished that I can't do this in Rebol proper.
I can't tell you not to *want* multi-threading, and I can't even say
that you won't need it in some specific instances. But how valuable is
it for 98% of the things we're doing, and does that outweigh the burden
it puts on us as developers? Not to mention RT having to build a
portable threading solution. :)
My experience is going to be a factor here. I've only done very
limited multi-threaded development, though I've read a *lot*. I
try to weigh the pros and cons objectively, but my preference is
naturally based on my own subjective view and experiences.
Now, before condemning (strong word, I know) a cooperative threading
approach, have you tried it and found it to be inadequate in some
respect?
While I don't feel a need to have a pre-emptive threading system in
REBOL, the topic does come up from time to time. Maybe someone should
write an article comparing and contrasting things--though that's been
done outside of a REBOL context.
BP> One way out of is to rely on cgi-bin as the multi-threaded server, but
BP> then every client invocation causes a new Rebol process to be launched,
BP> which is resource intensive (perhaps there is a way to jigger the
BP> apache.conf file to keep one or more processes running, but that's
BP> beyond me).
I think someone (Robert or Maarten?) cooked up an LRWP module for
REBOL to hook up to Xitami, not sure about Apache though.
I use this approach (spawning processes, not LRWP) in a project where
the hit rate is low and processes run a long time; it works well in
that environment.
-- Gregg
