[squeak-dev] Winds of change

Igor Stasenko siguctua at gmail.com
Sat Feb 7 01:26:25 UTC 2009


2009/2/7 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Fri, Feb 6, 2009 at 3:08 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> 2009/2/6 Steve Wart <steve.wart at 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.

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. :)

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 :)


>>
>> 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.



More information about the Squeak-dev mailing list