Re: more bugs in openmcl

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1264381705-1191877395=:47563
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE



On Mon, 8 Oct 2007, Far=E9 wrote:

> Dear bug-openmcl'ers,
>
> I am using openmcl on Linux x86-64, duplicating a CVS checkout from Gary =
Palter.
>
> In an attempt to port POIU to openmcl (a parallel variant of ASDF), I
> have found myself incapable of fork()ing in openmcl. When I (apropos
> "FORK"), I can see nothing, yet when I grep for fork, I find
> library/x8664-linux-syscalls.lisp:(define-syscall (logior
> platform-os-linux platform-cpu-x86 platform-word-size-64)
> syscalls::fork 57 () :signed-fullword)
> I tried to replicate that line at the top-level, to no avail: when I try =
to
> (in-package "CCL")
> (eval-when (:compile-toplevel :load-toplevel :execute)
>  (require "SYSCALL"))
> (define-syscall (logior platform-os-linux platform-cpu-x86
> platform-word-size-64)  syscalls::fork 57 () :signed-fullword)
> (ccl::syscall syscalls::fork)
> I get
>> Error: Undefined function %SYSCALL called with arguments (57 :SIGNED-FUL=
LWORD) .
>
> I must be doing something wrong, but I don't know what.


One might conclude that doing fork (except for the case of fork/exec)
isn't supported.

You could execute fork by doing

(ccl:external-call "fork" :int)

or using the #_ reader macro

(#_fork)

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.)


>
> Also, I know that SBCL hates it if you fork while multiple threads are
> running, as it confuses the internal thread management in the forked
> process. On SBCL, the workaround is to only use fork from a
> single-threaded SBCL (i.e. before any thread is spawned from the
> initial top-level). Is there any similar issue with OpenMCL, and what
> would a solution (or workaround) be?

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".

>
> 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.

>
> [ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.=
tunes.org ]
> God is omnipotent, omniscient and omnibenevolent -- it says so right here=
 on
> the label. If you have a mind capable of believing all three of these div=
ine
> attributes simultaneously, I have a wonderful bargain for you. No checks,
> please. Cash and in small bills.
>        -- Robert Heinlein, "Time Enough For Love"
>
> _______________________________________________
> Bug-openmcl mailing list
> [email protected]
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>
--0-1264381705-1191877395=:47563
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Bug-openmcl mailing list
[email protected]
http://clozure.com/mailman/listinfo/bug-openmcl

--0-1264381705-1191877395=:47563--