On Fri, Feb 6, 2009 at 5:26 PM, Igor Stasenko <siguctua@gmail.com> wrote:

2009/2/7 Eliot Miranda <eliot.miranda@gmail.com>:

>
>
> On Fri, Feb 6, 2009 at 3:08 PM, Igor Stasenko <siguctua@gmail.com> wrote:
>>
>> 2009/2/6 Steve Wart <steve.wart@gmail.com>:
>> > We were thinking about using Hydra for a recent project for this reason.
>> > Our
>> > FFI calls were doing network I/O that made it impossible to maintain an
>> > acceptable frame rate in Croquet.
>> >
>> > Unfortunately I didn't find the time to dig into this but our image size
>> > was
>> > already a problem and I assumed that this approach would make that
>> > problem
>> > worse. Maybe a Pharo image could exist on one thread to do network I/O
>> > and a
>> > regular Croquet thread could run on another thread?
>> >
>> > I recall that Hydra was released early because it was unexpectedly
>> > successful, but I haven't heard much about it since then.
>> >
>>
>> Yes Hydra FFI is multithreaded already.
>
> Does it support callbacks from threads? Does it support callbacks from
> threads other than threads that have called-out? (I call these callbacks
> foreign callbacks because they come from threads the Vm doesn't know exist
> until they callback)

there is no extra functionality (callbacks) in addition to what
original FFI plugin provides.
I'm only made sure that plugin's own state which used during
conversion of values is thread safe.

OK, so the FFI does *not* support threads. It is merely thread-safe so that multiple hydra instances can be making FFI call-outs at the same time.

That is an entirely different thing to an FFI that is multithreaded. I think you should claim only that the Hydra FFI is thread-safe, not that it is multi-threaded. It isn't. The common understanding of a multi-threaded FFI is one that allows one to call-out and call-ack on multiple threads.

A callback support , added by Andreas, is not related to FFI. It can
be used by plugins , and the only plugin i saw which using it was a
python bridge.

As for 'foreign' callbacks.. heh..
I would rather name it an async event/hook. :)

It is *not* an event hook. It is a means of invoking behaviour in the system being called. Call-back is the common term for this.

To my understanding a 'callback' term, its pattern which invented by
C-ers for passing a closure deeper into a stack i.e. callback function
should be called from within a function which takes it as argument and
never after it returns :

[1] sort(array, mySortFn);

[2]-> fnptr(x,y)
[callback] ... in mySortFn
[2]<- return from mySortFn

[1]<- return from sort()

where [1] is caller context, and [2] is function which using callback argument.

If it not behaves like this, then its not a callback anymore - call it
a hook, event or something else :)

I disagree. I think event hooks are far more specific tan call-backs.

Anyway...

>>
>> But all thread safety problems which may arise when you using foreign
>> modules are on your hands, of course.
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>

--

Best regards,
Igor Stasenko AKA sig.