From: MikkelFJ <mikkelj-anti-spam@...1.dknet.dk>
Date: 2001-07-29T22:09:42+09:00
Subject: [ruby-talk:18740] Re: Ruby as opposed to Python?


"Ned Konz" <ned@bike-nomad.com> wrote in message
news:EVI87.682$FR.46369@e420r-atl3.usenetserver.com...
> On Saturday 28 July 2001 05:20 pm, you wrote:

> I understand that VW now also fires up native threads for external DLL
calls.
> It didn't do this before, which would cause all the Smalltalk threads to
hang
> until the DLL call completed.

What about a native thread pool:
This might be complicated, but if a Ruby thread engages in external
activity, it is transferred to a native thread pool. In this way, the other
Ruby threads will not be disturbed, and the next external function call from
the Ruby thread will not require a context switch.

I justed looked at the Clean programming language. There is a Game API that
interfaces to Win32/ActiveX. But due overhead in context switching when
calling outside Clean, an alternative event model was tested, instead of
relying on C to Clean events because the threading issues had a high
overhead. Something like 30 vs. 200 smoothly moving objects by bypassing the
move object event. (The game API was written mostly in C and generates
events such as moveobject. This is probably compareable to Windows GUI
events).

This is a major issue. If I can only access 30 instead 200 database read
operations from some language pr. timeunit, this could be the difference
between using the language and not. Of course this should be compared to the
general overhead of a function call, which in the Ruby case may make the
thread overhead less relevant.

Mikkel