From: Paul Brannan <paul@...>
Date: 2002-02-25T23:41:34+09:00
Subject: Re: Ruby's Future

On Sat, Feb 23, 2002 at 01:47:38PM +0900, Sean Middleditch wrote:
> I didn't know Ruby had that in there.  Indeed, like you said, it is
> mostly undocumented.  But, you also mention hangs are possible...
> scripts, which are possibly entered by the user at runtime (depending on
> your application), should *never* have the ability to hang or crash your
> application.  If user data can ever cause a hang or crash, I consider it
> a serious bug ... user data cannot be trusted to be safe or accurate.

How, then, do you propose I handle callbacks?  If I need the result of
the callback in order to continue processing, then there's nothing I can
do until the callback has returned.  I can time out the operation, but
it's always possible that the operation would have completed had I given
it a few more seconds.

The only sane way to handle this is to allow the user to break out of
the script.  This is possible by running the UI in a separate thread.

> Well, again, that would make Ruby non-block... But say I have a script
> running in my app.  My app needs to respond to events (lets say user
> input).  If Ruby is blocking, the script runs, the whole app is
> unresponsive until the script is done blocking.  With the above code,
> the script would have to run in a loop or something, constantly checking
> the fd, which would not in any way necessary return execution context to
> the embedding app, and it would actually just cause an increae in CPU
> usage.

Same problem as above.  You need to wait on the result of an operation;
this is an appropriate use for blocking.  I'm not sure what else you
would propose be done.

Paul