[squeak-dev] Winds of change

Eliot Miranda eliot.miranda at gmail.com
Sat Feb 7 01:37:08 UTC 2009


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.




>
>
> 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.
>
>
Best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090206/22c8da4a/attachment.htm


More information about the Squeak-dev mailing list