Clemens Hintze wrote:
> 
> >>>>> "ts" == ts  <decoux / moulon.inra.fr> writes:
> 
> >>>>> "G" == Geoff Cadien <geoff / nm156.org> writes:
>     G> #include <pthread.h>
> 
>     ts>  ruby is multi threaded, this mean that you don't need to use
>     ts> pthread.
> 
> I believe that you even MUST NOT use pthread in ruby, indeed! Although
> Ruby is multithreaded it implements multithreading on its own via
> context switching using setjmp/longjmp.
> 
> I wouldn't be too surprised, if it would even not possible to use
> pthread here. Using pthread would probably require to synchronize
> things in the interpreter (e.g. saving/restoring of the current
> interpreter state). And, AFAIK, matz has not forseen such
> synchronization points for any other than Ruby's own multithreading
> scheme.
> 
> But this is not a disadvantage, IMHO! Ruby do threading very well
> without help from the OS ;-)

I used pthreads here to demonstrate the problem, not to create a
multithreaded ruby app using pthreads.  It's great that ruby is
multithreaded but what about embedding the interpreter in a
multithreaded app that already uses pthreads, for example Apache 2.0 or
AOLServer?  Has there been any discussion about implementing native
threads as opposed to user space threads in the interpreter?

-geoff