Fred Gilham <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Fabricio Chalub) writes: >> > someone has commented out the part that makes the socket use >> > nonblocking I/O. >> >> As a curiosity, from what I gather, CL-HTTP has two approaches for >> handling incoming connections: using MP:MAKE-PROCESS on >> tcp-interface-mp.lisp and using SERVE-EVENT ADD-FD-HANDLER on >> tcp-interface.lisp. The files are conditionally chosen in sysdcl.lisp, >> based on #+MP. There seems to be a deliberate choice (in CL-HTTP, that >> is) of using multithreading with blocking IO vs. SERVE-EVENT with >> nonblocking IO there, since in one file the line is commented out and >> the other it isn't. >> >> So, out of curiosity, how does CMUCL's SERVE-EVENT compare to a >> multithreaded solution in this case (or maybe in a general case of event >> handling)? Or you can't compare? Or am I totally lost here? ;) > > Your question made me realize how kludgy it is to use non-blocking I/O > here. I think processes (threads) are supposed to make blocking I/O > calls; those calls are actually wrappers around an entry into the > scheduler, which turns the call into a non-blocking call and makes the > process that made the call wait until the non-blocking I/O completes. > I don't think CMUCL does this kind of thing yet. FWIW, the CMUCL fd-streams code is able to handle non-blocking fds fine (retaining blocking semantics for the CL side), so that turning FDs into non-blocking mode (via unix:unix-fcntl) should automagically make processes yield when their writes/reads would block. Indeed, I think make-fd-stream should by default turn the passed FD into non-blocking mode (maybe overridable by a keyword argument). Regs, Pierre. -- Pierre R. Mai <[EMAIL PROTECTED]> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
