Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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