Helmut Eller said:
>
> Tom <[EMAIL PROTECTED]> writes:
>
>> A quick perusal of multi-proc.lisp suggests that it uses
>> some kind of user-level threading based on signals. What
>> seems to be happening is that the I/O operations performed
>> by CLX hang the process until some signal interrupts it
>> and a context switch happens.
[...]
>> How do other people write
>> multithreaded applications in CMU CL? This would seem
>> to be important for, say, a CL web server.
>
> I call process-yield explicitly in appropriate places. In the example
> above, I called process-yield after make-process.
>
> Some other approaches to increase responsiveness:
>
> - Start the idle loop with mp::startup-idle-and-top-level-loops
This also solves the problem of *initial-process* causing delays of a
second before e.g. newly created processes get a chance to run:
(defun startup-idle-and-top-level-loops ()
"Enter the idle loop, starting a new process to run the top level loop.
The awaking of sleeping processes is timed better with the idle loop
process
running, and starting a new process for the top level loop supports a
simultaneous interactive session. Such an initialisation will likely be the
default when there is better MP debug support etc."
(assert (eq *current-process* *initial-process*) ()
"Only the *initial-process* is intended to run the idle loop")
(init-multi-processing) ; Initialise in case MP had been shutdown.
;; Start a new Top Level loop.
(make-process #'top-level :name "Top Level Loop")
;; Enter the idle loop.
(idle-process-loop))
> - Don't use multi-threading at all. Use serve-event and friends
> directly. This should work reasonably well with CLX code. Hemlock is
> written this way.
>
> - Start the SIGALRM based preemptive scheduler
> (mp:start-sigalrm-yield). People say this is "dangerous" because some
> parts of the system have not been updated for handle
> multi-threading correctly. (But no one seems to know what parts are
> dangerous ;-)
This is exactly why we call it dangerous: We have 2nd order ignorance
about thread safety in the CMU CL code base. Most of the code in the code
base was written against a world where there was no preemptive parallelism
at the sub-lisp-primitive level. Auditing the code base for places which
need locking and/or other synchronization primitives added is yet to
happen.
> - Some people say it helps to make some file-descriptors non-blocking.
> I think this is even more dangerous than the preemptive scheduler.
Actually it should be much safer than the preemptive scheduler, in that
the only piece of code affected by the blocking state of the fd should be
the fd-stream machinery. And this was written with non-blocking
operations firmly in mind, although it probably hasn't been tested all
that much in real-world usage in recent times.
Still, I'd feel comfortable making fd's non-blocking by default when they
are passsed to make-fd-stream (overridable by a keyword flag and/or
special variable).
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
