[plt-scheme] Re: Using LibFFI along with threads
Hmm. Let's see. I can test on the following platforms:
OSX
Linux (slackware 8, suse 10)
Windows XP
FreeBSD --> I can make a vmware image.
Solaris: I can't test that.
AIX 5.3: I could test that.
Most platforms support pthreads though.
Note however the code in the 'gc' subdir:
# include "gc_config_macros.h"
# include "private/gcconfig.h"
# include <stdio.h>
int main()
{
# if defined(GC_USE_LD_WRAP)
printf("-Wl,--wrap -Wl,dlopen "
"-Wl,--wrap -Wl,pthread_create -Wl,--wrap -Wl,pthread_join "
"-Wl,--wrap -Wl,pthread_detach "
"-Wl,--wrap -Wl,pthread_sigmask -Wl,--wrap -Wl,sleep\n");
# endif
# if defined(GC_LINUX_THREADS) || defined(GC_IRIX_THREADS) \
|| defined(GC_SOLARIS_PTHREADS) \
|| defined(GC_DARWIN_THREADS) || defined(GC_AIX_THREADS)
printf("-lpthread\n");
# endif
# if defined(GC_FREEBSD_THREADS)
# if (__FREEBSD_version >= 500000)
printf("-lpthread\n");
# else
printf("-pthread\n");
# endif
# endif
# if defined(GC_NETBSD_THREADS)
printf("-lpthread -lrt\n");
# endif
# if defined(GC_HPUX_THREADS) || defined(GC_OSF1_THREADS)
printf("-lpthread -lrt\n");
# endif
# if defined(GC_SOLARIS_THREADS) && !defined(GC_SOLARIS_PTHREADS)
printf("-lthread -ldl\n");
# endif
# if defined(GC_WIN32_THREADS) && defined(CYGWIN32)
printf("-lpthread\n");
# endif
# if defined(GC_OSF1_THREADS)
printf("-pthread -lrt"); /* DOB: must be -pthread, not -lpthread */
# endif
/* You need GCC 3.0.3 to build this one! */
/* DG/UX native gcc doesnt know what "-pthread" is */
# if defined(GC_DGUX386_THREADS)
printf("-ldl -pthread\n");
# endif
return 0;
}
It all seems to be pthreads, except for standard windows of course.
Best wishes,
hans
Eli Barzilay schreef:
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070717/ac236eaf/attachment.html>