[Prev][Next][Index][Thread]
Re: updating an icon label in DUIM
Eric Gouriou wrote in message <396BEBFD.8F844C25@cup.hp.com>...
>
>John Whittaker wrote:
>[...]
>>[...] I saw a recent
>> post about timing of continuation based threads versus native OS threads
in
>> comp.lang.scheme. The continuation based threads just ran rings around
most
>> native OS threads in terms of both speed and resource usage (as I
recall),
>> with the absolute worst being native Linux threads.
>
> Linux is not known for having good threading support. And it seems that
>Linux Torvald's beliefs in the rightness of the Linux process/thread design
>is blocking efforts to change this. It would be interesting to
>provide a similar comparison on other OSes.
>
> To be fair, it also seems that the comparison involved a user-level
threading
>package (continuations) vs. a kernel-level threading package. Those are
different
>beasts and the trade-offs are well documented in the CS literature. Was
>the continuation package "fair" (guarantees that every thread will run
eventually),
>pre-emptive ? Could it take advantage of more than one processor ? How does
it scale ?
>These differences are easily overlooked when comparisons are not done with
>high-end servers in mind. Testing on an OS supporting a M*N thread
implementation
>would also be interesting.
>
It was an explicit goal of Harlequin/Functional Dylan that Dylan
interoperate with native threads. I did not initially think this was
a good idea, for exactly the reasons John Whittaker lists, but
I changed my tune in the face of the importance of interoperability
at the shared library level.
References: