Hi Dmitris,
(define do-read(c-lambda (scheme-object) int#<<END-Cchar buf[4096];___SCMOBJ ctx = ___EXT(___make_vector)(2, ___FAL, ___STILL);___VECTORSET (ctx, ___FIX(0), ___arg1);for (;;) {if (do_read ((void*)ctx, buf, sizeof(buf)) < 0) break;}END-C))
(lambda (v)(let ((buf (make-u8vector 4096))(ctx (make-still-vector 2 #f)))(vector-set! ctx 0 1)(let loop ()(if (< 0 (do-read ctx buf (u8vector-length buf)) (loop)))
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
>>
>