>>>>> "cm" == Chakravarthi Muralidar <[EMAIL PROTECTED]> writes:
cm> The problem here is that if one connection starts writing data (and cm> analyze-i is started since the stream has data)...i.e., analyze-i is cm> reading the data and writing to disk..other processes has to wait till cm> this one is complete why is that?? the multiprocessing support in CMUCL is based on user-level coroutines (or "green theads"), and not on kernel threads. Scheduling is cooperative: processes must explicitly yield control to allow other processes to run. However, I/O operations on fd-streams yield implicitly, so I'm surprised that one of your processes blocks the other by doing I/O (the opposite should be happening). You could try experimenting with different values for the LISP::FD-STREAM-TIMEOUT of your network streams, to see whether that improves scheduling, but if you really to protect against blocking you should be using multiple CMUCL processes. Also note that SBCL has some support for native threads on x86/Linux (and funding could accelerate development). cm> (In other words why is the second listener process or the first cm> listener process have lower priority than the (analyze-i) cm> process..is there something i can do to fix this... CMUCL's multiprocessing does not support priorities on processes. -- Eric Marsden <URL:http://www.laas.fr/~emarsden/>
