<br><br><div class="gmail_quote">On Fri, Feb 6, 2009 at 3:08 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">2009/2/6 Steve Wart <<a href="mailto:steve.wart@gmail.com">steve.wart@gmail.com</a>>:<br>
</div><div class="Ih2E3d">> We were thinking about using Hydra for a recent project for this reason. Our<br>
> FFI calls were doing network I/O that made it impossible to maintain an<br>
> acceptable frame rate in Croquet.<br>
><br>
> Unfortunately I didn't find the time to dig into this but our image size was<br>
> already a problem and I assumed that this approach would make that problem<br>
> worse. Maybe a Pharo image could exist on one thread to do network I/O and a<br>
> regular Croquet thread could run on another thread?<br>
><br>
> I recall that Hydra was released early because it was unexpectedly<br>
> successful, but I haven't heard much about it since then.<br>
><br>
<br>
</div>Yes Hydra FFI is multithreaded already.</blockquote><div><br></div><div>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)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
But all thread safety problems which may arise when you using foreign<br>
modules are on your hands, of course.<br>
<font color="#888888"><br>
<br>
--<br>
</font><div><div></div><div class="Wj3C7c">Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>