From: Avi  Bryant <avi.bryant@...>
Date: 2005-04-09T19:54:42+09:00
Subject: Re: Seven new VMs, all in a row


Lothar Scholz wrote:
> Hello Peter,
>
> PS> Why is it that you'd want real threads?  What can real threads do
that
> PS> Ruby VM threads can't do?  The answer is synchronous calls out to
OS
> PS> services.  (As well as utilizing multiple processors, but that's
> PS> another issue.)
>
> Having a database app where each "fetch_row" call into the database
> driver have to do at least 2 sync operations and 2 thread schedules
> really scares me when we are talking about high performance VM's.

You don't *have* to do external calls in a separate thread, it's just
that you can where it's useful (ie, blocking I/O calls like making
database queries).  For something like fetch_row, you might just use
the normal, older callout mechanism, which does what Ruby does: blocks
the whole VM until you return.

Like Ruby, Smalltalk implementations generally use non-blocking I/O
(made to look like blocking I/O from the point of view of the
language's threads), so native threads are only needed when the DLL
you're calling into only provides a blocking API.

Anyway, unlike much of the VisualWorks VM, this part is actually quite
well documented:
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/VisualWorks+THAPI

Avi