[Bug-openmcl] more bugs in openmcl

[Faré]

On 08/10/2007, Gary Byers <gb at clozure.com> wrote:
> You could execute fork by doing
>
> (ccl:external-call "fork" :int)
>
> or using the #_ reader macro
>
> (#_fork)
Thanks a lot!

> Once you do that, I have no idea what happens next.  On Darwin, threads
> in the forked process don't have their Mach exception ports set up
> correctly (or didn't as of the last time I checked), so even the fork/
> exec case has to be extremely careful not to do anything that could
> cause an exception.  (Consing can cause an exception.)
Who would know about the linux port?


> There likely is a similar issue (aside from the known issues on Darwin);
> for all practical purposes, there's no such thing as "single threaded
> OpenMCL".
Too bad.

> > Note that this issue is not one of using fork followed by exec. When
> > you fork then in the child you exec before you had the opportunity to
> > mess with the Lisp and/or C threading runtime support, then you
> > needn't fear anything. But in this particular case, I really do not
> > want to exec, just to fork and then call COMPILE-FILE in the child.
>
> Hmm.  If only there was another obvious way to exploit parallelism in
> a multi-threaded lisp.  If only there was an obvious way to create
> parallel ... oh, let's call them "threads" ...  of execution.
>
Because of subtle race conditions, compilation in SBCL is protected
using a big compile lock. Also, increased memory pressure means more
GC, which is single-threaded even in a multiprocessor machine and
requires expensive interprocess synchronization.

Are there no such issues in OpenMCL? Can I safely spawn tens of
COMPILE-FILE threads, and have the system respond correctly and
actually benefit from multiple CPU cores for increased performance?

But you're right. POIU should probably have a thread-based model as
well as a fork-based model. If I do it, however, what is the way to
get debugging right in this setting? In the current fork-based model,
if a child fails, we restart the failing computation on the top-level
process, which will likely fail similarly and provide a debugging
interface right at the normal expected top-level terminal. How should
I do things in a multithreaded environment (specifically OpenMCL's) ?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
"How many libertarians does it take to change a lightbulb?"
A- "None, the market will take care of it."
B- "Every one of them and non-libs too, because we all *are* the market."
C- "*I*'ll do it, for a dollar."