Re: [Chicken-users] An alternative thread system?

[Elf]

We are not doing native threads. 
Period.

Brief explanation:

I've been spending most of the last 6 months, now, just trying to get 
I/O working properly on the various platforms we support.  Threading is 
right out of the question.  There are too many threading models on our 
supported platforms, very few of which have compatible semantics.  Just 
trying to keep the bugs from a multiplatform threading implementation 
under control would be a more-than-fulltime job.  This is why

NO KNOWN MULTIPLATFORM LANGUAGE IMPLEMENTATIONS HAVE WORKING NATIVE THREADING.
NO KNOWN MULTIPLATFORM LIBRARY IMPLEMENTATIONS HAVE WORKING NATIVE THREADING.

There is a reason for this.  If you don't believe me, delve into the source
and bugtree of whatever language you claim does support native threading on
windows, macosx, and at least two unixes.

If you want to take advantage of multiprocessing, spawn new processes.  There
are already all kinds of synchronisation and communication and distributed
programming eggs out there.

The blocking I/O issues will be cleaned up very shortly, and I agree they are
annoying. :)


-elf
(thread-terminate! "[Chicken-Users]: re: thread-terminate!")
too bad :)



On Sun, 10 Aug 2008, Adam C. Emerson wrote:

> Good evening, gentle creatures,
>
> Whatever overhaul the interface and model get, I think the
> implementation needs some work, too.  I/O blocking everything (with
> the exception of TCP and the REPL) is somewhat annoying.  Having green
> threads keeps Scheme programs from taking advantage of multiple
> processors.  And, while dangerous, it would also be nice to have other
> threads continue running while one is blocked in a C library call,
> though obviously the programmer would have to know his library and not
> schmutz things up.
>
> Thank you.
>
>
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users