[squeak-dev] Winds of change

Igor Stasenko siguctua at gmail.com
Sat Feb 7 02:06:38 UTC 2009


2009/2/7 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Fri, Feb 6, 2009 at 5:26 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> 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.
>
> 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.
>
>

I known there's Alien flying around, which supports FFI callbacks.
And we have two choices: adopt Alien, or add callbacks to current FFI
implementation :)

A God has gathered all living creatures in same place and said:
- beatiful ones, stand to left side
- intelligent ones, stand to right side.
All animals choosed own side quickly, and only ape keeps standing in a centre.
- Why you not moving, didn't you heard what i just said? - asks God.
- Its hard to choose, because i'm both beatiful and intelligent.


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

Okay then, a i understood, by callback, you mean passing a function
pointer anywhere you like to, and expect it to be called from any
thread at any moment since then.
Its a most generic way, which covers all use cases, except those when
developer is complete idiot :)

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list