I'd like to clarify something about Andreas Thiele's failed attempts at =
getting his .dll to run.
He explained to me that he suspects what I'd call a "design bug", which =
I believe must cause crashes in CLISP: his .dll creates a thread which =
would callback into Lisp.
I don't know what CLISP-win32 does, but doing so would definitely crash =
the Amiga. A callback should only occur from the same thread.
1. The second thread is likely to see bad register variables (e.g. =
STACK) and crash. Even if it does not,
2. In effect, two threads would be working concurrently on the CLISP =
heap and STACK, which is a guarantee for a crash.
3. Furthermore, IIRC non-local transfer of control happen (via throw or =
error) uses some stored information about the original machine stack =
which doesn't make sense when used from another thread.
Now Andreas is successfully building his library under Lispworks (which =
supports threads) where it seems to work. Nevertheless, I'd like to =
have this issue confirmed or denied if possible.
One could argue such a configuration might be made to work if there's =
no concurrency w.r.t. CLISP. All that then counts would be that the =
calling thread has set the right variables and context. I don't know if =
this is the case for Andreas' code.
I.e. this *might* possibly work (but e.g. on Amiga, the other thread =
should not use the first one's filehandles, I don't know whether there =
are similar restrictions on MS-Windows):
1. Lisp call foreign
2. foreign starts thread and loops until some stop signal
3. thread creates event loop
4. threads calls back into lisp
5. Lisp does something and returns into foreign land
6. repeat 4-5 a few times
7. thread sends stop signal to parent and terminates (or at least does =
not do anything to Lisp)
8. initial foreign call terminates, returning to Lisp
Non-local transfer of control between the two threads must probably be =
avoided at all costs (i.e. callback signaling a condition)!