Switching threads off is not an option because of I/O.
So basically you are saying that ffi scheme upcalls (through c-define'd lambdas) are not thread safe (scheme threads always). I would expect each thread to maintain its own c stack, but apparently it is not so and C-stacks cannot be safely interleaved with multiple threads.
If this is the case, it is a pretty serious limitation in the ffi.
PS: wiki seems down again
On Sat, Feb 23, 2013 at 1:14 AM, Mikael mikael.rcv@gmail.com wrote:
Dimitris,
(From only looking very generally at your code,)
May this be a stack unwinding problem?
If you unwind a stack other than in the same order it was wound in the first place, your Gambit process will terminate or at least crash.
Example:
You have a lambda A that invokes C-lambda B that invokes lambda C.
Also, a lambda D that invokes C-lambda E that invokes lambda F.
If you invoke A and A invokes B and B invokes C,
and then say, Gambit switches thread, and that Gambit thread invokes D which invokes E which invokes F,
and then, say, Gambit switches thread again, and that Gambit thread returns from C to B.
Then your Gambit process is toast.
To handle this you can switch off Gambit's threading system when you're in B or E for the course of your C and F calls respectively. Note that switching off Gambit's threading system means that some or several of Gambit's built-in IO primitives would block forever.
See the "How to work with external libraries" Wiki page for how to switch it off.
Was this of help?
Mikael
2013/2/23 Dimitris Vyzovitis vyzo@hackzen.org
I am running into an abrupt exit with error code 71 (OSError) when multiple (scheme) threads are making ffi calls that upcall to scheme.
A simplified scenario (see attached file) is as follows: 2 or more threads make an ffi call. The ffi call is a longer running procedure, that makes upcalls into scheme procedures that do I/O. This results in the program exiting abruptly with error code 71, and no context information regarding the error (even when compiled and running with full debugging).
For an illustration of the problem, see the attached file.
The following should print dots indefinitely, but instead quickly terminates with 71.
$ gsc exit71.scm $ gsi -e "(begin (load "exit71") (main))" ....<plenty of dots>.... $ echo $? 71
This is with gambit-4.6.6, system is GNU/Linux x86-64.
-- vyzo
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list