From: Marc B. <mar...@fr...> - 2003-04-05 20:17:25
|
Daniel Barlow writes: > [ CCed to lispweb, where it may catch the attention of more people > interested in Web programming ] Sure, it's nice to see there is some life in this list... > Kevin Rosenberg <ke...@ro...> writes: > > > I'd like to use sb-threads with modlisp. I wonder if someone familar > > with application programming with sb-threads would review the > > following two functions that use cmucl's threads and share their > > insight how to optimally port to sb-threads. [...] > OK, so what the code here seems to be doing is spawning a thread for each > listening socket (I doubt there are too many of these), then a new > thread for each accepted connection. I don't know if mod_lisp uses > the same connection for multiple requests or not. Generally yes, there is one socket connection between each Apache process and the Lisp process. And each connection can handle an unlimited number of requests. > This can be translated fairly mechanically into the SBCL thread api: > use sb-thread:create-thread instead of mp:make-process, and > sb-sys:wait-until-process-usable instead of > mp:wait-until-process-usable (one of the nice things about kernel > threading: blocking operations don't block the rest of lisp :-) What memory allocation/GC strategy have you choosen for the threads ? (Maybe there is some doc that describes it ? (URL ?)) > However: SBCL threads are presently pretty heavyweight things. > Although the kernel guys have lavished a certain amount of attention > on making thread creation lightweight, it's still a kernel task, plus > we need to allocate stacks and so on - eventually we'll resource > these, but getting it to work right is presently a priority over work > fast. With that in mind, my gut instinct (I haven't benchmarked) says > it's better to make them do a little more work in their life than one > request each. Sure. Marc |