[Openmcl-devel] Re: New OpenMCL 0.14 binaries (not visually compelling ...)

[Gary Byers]

On Fri, 8 Aug 2003, Eric Marsden wrote:

> >>>>> "gb" == Gary Byers <gb at clozure.com> writes:
>
>   gb> There were some substantial changes to some parts of the
>   gb> process/thread API; these are documented in greater detail in
>   gb> "ccl:doc;HTML;threads.html". Code that tries to maintain "thread
>   gb> pools" via PROCESS-RESET/PROCESS-PRESET/ PROCESS-ENABLE should
>   gb> now work much more reliably; since it wasn't at all reliable in
>   gb> previous 0.14 releases, any improvement would be much more
>   gb> reliable.
>
> so it's more reliable, but I'm afraid that it still crashes when
> two threads are compiling simultaneously. It breaks to the low-level
> debugger, and attempting to obtain a backtrace makes it abort (same
> behaviour on LinuxPPC and Darwin).
>
> The easiest way to reproduce this is to download the most recent
> cl-bench from <http://www.chez.com/emarsden/downloads/>. This attempts
> to use a thread pool to compile the microbenchmarks concurrently.
>
>    bash run-openmcl.sh
>
>

You're still calling (PROCESS-RESET *CURRENT-PROCESS*), then trying to
have the current thread push itself onto the thread pool and signal
the esmaphore.  That doesn't explain why you're crashing, but it can't
possibly cause the thread to be added to the thread pool or the semaphore
to be signaled.  As I explained in an earlier message, you probably want
the PROCESS-RESET to be the last thing that the thread does.

As far as the crash and difficulty with backtrace are concerned, your
shell script invokes OpenMCL with a --stack-size argument of 256.  The
lisp probably shouldn't let you create a 256 byte stack; I'd be very
suspicious of anything that happens after it's let you do wo.

> Please note that I don't have any urgent need for concurrent
> compilation from multiple threads; I am just submitting this as a
> stress test of the native threads.
>


Setting the stack size of the initial thread to 256 bytes certainly
constitutes a stress test, but I doubt if that's intentional.

If I run

% sh run-openmcl.sh

with the --stack-size argument allowed to default, things behave as I'd
expect: the "cl-bench" threads reset themselves, and the main listener
thread is waiting for the semaphore that they'll never signal.


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel