[plt-scheme] Re: Using LibFFI along with threads
Hans Oesterholt-Dijkema wrote:
> Hi Tom,
>
> That's exactly what I want. PLT Scheme (DrScheme,MzScheme)
> doesn't do OS threads. In real life this means that a call to a
> native C function will block your entire scheme language
> including all "threads" in scheme.
>
> Imagin a long database query blocking all your threads, or
> a inserter thread doing inserts on a database, blocking your
> entire user interface.
>
> What I want is to do a "non blocking" call to a C function, by
> starting the C function in an OS thread and let the current scheme
> thread wait for the result, while allowing other scheme threads
> to run. I've done this trick already in the past, but without the
> FFI. However, it needs a littlebit of C code that must be compiled,
> and the goal of using the ffi is to allow for native C bindings
> without the need to compile glue code.
>
> I've looked into the foreign code of PLT Scheme yesterday and I
> think it is actually extremely easy to allow for a non blocking
> ffi call, that only blocks the current scheme thread, but no others.
>
>
But Scheme thread is not OS level thread. I have played with C thread
before too, and here is some of my experience:
1. SCHEME_USE_FUEL() doesn't work at all. SCHEME_USE_FUEL(100) is called
periodically , but I can't see other Scheme thread got CPU (even
DrScheme stop to react). I don't know why.
2. scheme_check_thread() works in most cases. But I notice that with 3m,
if src/mzscheme/gc2/xsrc/ is used, it may cause segfault during stack
swapping. On my computer, src/mzscheme/gc2/xsrc/ is not used, so I'm not
sure why either.
3. scheme_block_until() and related works the best.
So, I guess your "extremely easy" way "to allow for a non blocking that
only blocks the current scheme thread, but no others" should be build on
top of scheme_block_until(), putting the "a little bit of C code glue"
into FFI. Right?
> Maybe I'll propose a small code change in the foreign code of
> PLT Scheme.
>
> --Hans
>
>
>
>