[plt-scheme] Re: Using LibFFI along with threads

From: Hans Oesterholt-Dijkema (hdnews at gawab.com)
Date: Tue Jul 17 17:39:40 EDT 2007

Hmm. Let's see. I can test on the following platforms:

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)
#   endif
#   if defined(GC_FREEBSD_THREADS)
#       if (__FREEBSD_version >= 500000)
#       else
#       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)
#   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,


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>

Posted on the users mailing list.