hello,
I have a big dll which is working with sockets and
so on.
I’v wrote a wrapping-extension for this dll and there is a
problem that ruby crash.
the dll has a worker thread which is waiting for
data. On arrival of some data the thread calls a ruby
block with
rb_funcall(block, rb_intern(“call”), 1, INT2NUM(n) );
If I do this ruby crash.
The callback is asynchronous.
There a two ways:
- find a way to call the block from this foreign thread
- poll in a ruby thread.
The second way is very ugly.
Is there a way in ruby to synchronize this?
daniel
Sorry, but Guy[*] has already answered this for you:
http://ruby-talk.org/69913
If you don’t like the answer you got first time round, simply asking the
question again is unlikely to get the desired result 
Regards,
Brian.
[*] You should definitely listen to what this man says.
···
On Fri, Apr 25, 2003 at 03:32:16AM +0900, daniel wrote
I have a big dll which is working with sockets and
so on.
I’v wrote a wrapping-extension for this dll and there is a
problem that ruby crash.
the dll has a worker thread which is waiting for
data. On arrival of some data the thread calls a ruby
block with
rb_funcall(block, rb_intern(“call”), 1, INT2NUM(n) );
If I do this ruby crash.
The callback is asynchronous.
There a two ways:
- find a way to call the block from this foreign thread
- poll in a ruby thread.
The second way is very ugly.
Is there a way in ruby to synchronize this?
Brian Candler wrote:
[…]
[*] You should definitely listen to what this man says.
hm,…
Ohter languages (tcl) own’s a method to
manage this.
I’v tried a APC(*)-Function and this works.
But ruby-functions like sleep does not work
with the apc…
polling is ugly,… 
daniel
(*) asynchronous procedure call (vc, win$)
···
On Fri, Apr 25, 2003 at 03:32:16AM +0900, daniel wrote
Wouldn’t having a ruby-interface thread do the job? Just have the
foreign thread call the ruby-interpreter thread, which passes the call
to ruby – right?
Aredridel
···
On Thu, 2003-04-24 at 14:52, Brian Candler wrote:
On Fri, Apr 25, 2003 at 03:32:16AM +0900, daniel wrote
I have a big dll which is working with sockets and
so on.
I’v wrote a wrapping-extension for this dll and there is a
problem that ruby crash.
the dll has a worker thread which is waiting for
data. On arrival of some data the thread calls a ruby
block with
rb_funcall(block, rb_intern(“call”), 1, INT2NUM(n) );
If I do this ruby crash.
The callback is asynchronous.
There a two ways:
- find a way to call the block from this foreign thread
- poll in a ruby thread.
The second way is very ugly.
Is there a way in ruby to synchronize this?
Sorry, but Guy[*] has already answered this for you:
http://ruby-talk.org/69913
If you don’t like the answer you got first time round, simply asking the
question again is unlikely to get the desired result
matz@ruby-lang.org (Yukihiro Matsumoto) wrote in message news:1051225465.365698.19097.nullmailer@picachu.netlab.jp…
Hi,
Ohter languages (tcl) own’s a method to
manage this.
Pretty interesting. I’d like to hear about how other languages solve
this kind of problems. API example, please?
Last time I tried Tcl/Tk did not work well with native threads.
Probably they did something since then.
matz.
some text about tcl and manage events…
···
In message “Re: asynchronous ruby” > on 03/04/25, daniel offstuff@aon.at writes:
–
These procedures provide a safe mechanism for dealing
with asynchronous events such as signals. If an event
such as a signal occurs while a Tcl script is being
evaluated then it isn’t safe to take any substantive
action to process the event. For example, it isn’t
safe to evaluate a Tcl script since the interpreter
may already be in the middle of evaluating a script;
it may not even be safe to allocate memory, since a
memory allocation could have been in progress when the
event occurred. The only safe approach is to set a flag
indicating that the event occurred, then handle the event
later when the world has returned to a clean state, such as
after the current Tcl command completes.
–
I’m searching for a similar method to handle my events
and callbacks…
daniel
Ruby handles signals in the same way. If it’s in the middle of doing
something then all the signal handler does is sets a flag, which gets
processed at the next sensible opportunity.
But I don’t think you can use signals as a way of communicating between
threads. You’d need a separate mechanism whereby Ruby blocks on some other
thread-safe entity (a semaphore perhaps) and takes an action.
Perhaps you could just set up a pipe between your threads. Ruby can select()
on one end the pipe, waiting for you to send a message down it.
Regards,
Brian.
···
On Fri, Apr 25, 2003 at 06:37:45PM +0900, daniel wrote:
–
These procedures provide a safe mechanism for dealing
with asynchronous events such as signals. If an event
such as a signal occurs while a Tcl script is being
evaluated then it isn’t safe to take any substantive
action to process the event. For example, it isn’t
safe to evaluate a Tcl script since the interpreter
may already be in the middle of evaluating a script;
it may not even be safe to allocate memory, since a
memory allocation could have been in progress when the
event occurred. The only safe approach is to set a flag
indicating that the event occurred, then handle the event
later when the world has returned to a clean state, such as
after the current Tcl command completes.
Brian Candler wrote:
–
These procedures provide a safe mechanism for dealing
with asynchronous events such as signals. If an event
such as a signal occurs while a Tcl script is being
evaluated then it isn’t safe to take any substantive
action to process the event. For example, it isn’t
safe to evaluate a Tcl script since the interpreter
may already be in the middle of evaluating a script;
it may not even be safe to allocate memory, since a
memory allocation could have been in progress when the
event occurred. The only safe approach is to set a flag
indicating that the event occurred, then handle the event
later when the world has returned to a clean state, such as
after the current Tcl command completes.
Ruby handles signals in the same way. If it’s in the middle of doing
something then all the signal handler does is sets a flag, which gets
processed at the next sensible opportunity.
But I don’t think you can use signals as a way of communicating between
threads. You’d need a separate mechanism whereby Ruby blocks on some other
thread-safe entity (a semaphore perhaps) and takes an action.
afaik, ruby is not thread-safe.
tcl is (since version 8 or so).
Perhaps you could just set up a pipe between your threads. Ruby can select()
on one end the pipe, waiting for you to send a message down it.
I’ll try this, thx.
daniel
···
On Fri, Apr 25, 2003 at 06:37:45PM +0900, daniel wrote: