[plt-scheme] Re: Using LibFFI along with threads
On Jul 17, Hans Oesterholt-Dijkema wrote:
> Dear Eli,
>
> Thanks for your elaborate reply. I must admit that you are right on
> a lot of points. There's one advantage of having the "non blocking"
> ffi call, and that is: one keeps access to the returned C results,
> without having to serialize the results over a pipe.
Yes, but that's not a big problem. Instead of some
(define foo (non-blocking-call ....)) ; returns a foo pointer
(printf "foo->bar = ~s\n" (foo-bar foo))
(printf "foo->blah = ~s\n" (foo-blah foo))
you can do this:
(define foo (gensym))
(send-subprocess `(define ,foo (blocking-call ...)))
(printf "foo->bar = ~s\n" (send-subprocess `(foo-bar ,foo)))
(printf "foo->blah = ~s\n" (send-subprocess `(foo-blah ,foo)))
(And a few macros can make it even more transparent...)
This is equivalent to the foreign machinery that pulls off values from
a C object.
> That said. The current mzscheme source distribution depends already
> on threads afaik (have a look in the gc subdir?).
But it does assume that Scheme execution is done on a single thread.
For example, using Scheme callbacks will probably break things if done
on a different thread. But this is obviously a problem either way,
subprocess, fork, or whatever. (And, for example, being able to
serialize closures would be a solution in all of cases.)
In any case, let me clarify: I do believe that async calls *are*
useful. If you can verify that the c-threads code that you wrote
works fine on Windows, OSX, Linux, BSD, and Solaris then it would be a
good starting point to integrate that in. (If you don't have access
to these platforms, then perhaps you can write enough test cases and I
can run them.) Yes, callbacks from a thread would break things -- but
the reason for the `(unsafe!)' statement is that you can break things
anyway, so it's probably fine to throw that on the programmer's
shoulders.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!