orbit-python-list

[Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

Hey there,

I'm wondering if it's at all possible to catch signals (SIGINT would be
nice, but any signal is something already) when I've issued an
orb.run(). The default effect is getting all the handlers remapped to
somebody's default handlers.. I have yet to find out who's exactly
(SIGALRM, for example, prints "Alarm!" and quits). I'm sure they can be
remapped, somehow, but how?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Jason T. <ta...@li...>]

> orb.run(). The default effect is getting all the handlers remapped to
> somebody's default handlers.. I have yet to find out who's exactly
> (SIGALRM, for example, prints "Alarm!" and quits). I'm sure they can be
> remapped, somehow, but how?

Whatever the cause of this, it's not entirely obvious to me either.  I
have some free time tonight so I'll see if I can figure out what's going
on. :)

Jason.

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Wed, 29 Nov 2000, Jason Tackaberry wrote:

> Whatever the cause of this, it's not entirely obvious to me either.  I
> have some free time tonight so I'll see if I can figure out what's going
> on. :)

If you have an idea of where I can start looking I promise I'll try
digging in myself, so let me know.

Unrelated: would orbit-python work with orbit-mt? I'm asking because it
seems rather simple to multithread a python app with orbit, but if orbit's
not thread-safe all sorts of ugly things could happen, couldn't it?

I have this event problem to look over.. still haven't got around to
finding out if a push-push server is workable.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Jason T. <ta...@li...>]

> If you have an idea of where I can start looking I promise I'll try
> digging in myself, so let me know.

Not at this point.  As soon as I find something I'll let you know.

> Unrelated: would orbit-python work with orbit-mt? I'm asking because it
> seems rather simple to multithread a python app with orbit, but if orbit's
> not thread-safe all sorts of ugly things could happen, couldn't it?

I committed some changes to CVS back in August to make ORBit-Python
thread-safe by using the global interpreter lock, but I have some
reservations about the correctness of this code.  My initial thoughts
were that Python's interpreter will prevent two threads from
simultaneously calling ORBit functions, but I may want to reinvestigate
this, especially since Roland's bug report in September (see the list
archives).

I don't know much about orbit-mt, but my impressions from what I've read
on the project's webpage is that it would be workable with ORBit-Python
with some trivial changes.

Jason.

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Jason T. <ta...@li...>]

> If you have an idea of where I can start looking I promise I'll try
> digging in myself, so let me know.

I believe I've found the source of the problem, but I'm not confident I
know how to fix it.  From the documentation for the signal module:

- Although Python signal handlers are called asynchronously as far as
  the Python user is concerned, they can only occur between the
  ``atomic'' instructions of the Python interpreter. This means that
  signals arriving during long calculations implemented purely in C
  (e.g.  regular expression matches on large bodies of text) may be
  delayed for an arbitrary amount of time.

When the ORB's run method is called, it in turn calls CORBA_ORB_run
which starts the main loop.  So, control is not returned to the Python
interpreter until a CORBA event happens.  This means by using the signal
module, if the program receives a signal for which a custom handler is
installed, the handler will not be called until some event happens (a
client invokes a method from the server, or the ORB exits, for example).

One possible fix would be to install a custom handler for all signals
just before entering CORBA_ORB_run that somehow allows the interpreter
to take control in order to call the handler set using the signal
module.  I have a hunch this may not be the best solution. :)  Surely
someone else has had to deal with this problem.  I'd love some help in
resolving this.  It's probably nothing a note to c.l.p couldn't solve,
but if anyone on this list has some insight, please speak up. :)

Jason.

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Wed, 29 Nov 2000, Jason Tackaberry wrote:

> When the ORB's run method is called, it in turn calls CORBA_ORB_run
> which starts the main loop.  So, control is not returned to the Python
> interpreter until a CORBA event happens.  This means by using the signal
> module, if the program receives a signal for which a custom handler is
> installed, the handler will not be called until some event happens (a
> client invokes a method from the server, or the ORB exits, for example).

Yes, it does seem to be the case. Interesting that if you set a handler
for a signal which CORBA (or python, I can't say) has a default handler,
it never get called, whereas if you signal a default handler it does
work. E.g, for the fragment:

orb=CORBA.ORB_init(sys.argv,CORBA.ORB_ID)
orb.run()

I get:

blackjesus:~/devel/pyorb> kill -ALRM %2
[2]    Alarm clock                   ./run

But for the fragment:

def handle_alarm():
    print "Foo!"
    exit

signal.signal(signal.SIGALRM, handle_alarm)
orb=CORBA.ORB_init(sys.argv,CORBA.ORB_ID)
orb.run()

I get nothing at all:

blackjesus:~/devel/pyorb> kill -ALRM %2
blackjesus:~/devel/pyorb> 

The process keeps on running. So some handlers are actually called - just
user-defined ones aren't. I don't know if this is because we're using
CORBA's default handlers.

> One possible fix would be to install a custom handler for all signals
> just before entering CORBA_ORB_run that somehow allows the interpreter
> to take control in order to call the handler set using the signal

What call do I have to produce to get the interpreter to handle signal
requests? I've managed to implement a dummy handler here that does what I
want, but how to I let python handle the events?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Jason T. <ta...@li...>]

> The process keeps on running. So some handlers are actually called - just
> user-defined ones aren't. I don't know if this is because we're using
> CORBA's default handlers.

I assume this is because of the global interpreter lock.  When the
process receives a signal that was set by the signal module, it enters
the Python stub function to call the custom handler back in Python
space, but it blocks until the interpreter lock is released which won't
happen until some CORBA event occurs.

'course I could be wrong, but it makes sense. :)

> What call do I have to produce to get the interpreter to handle signal
> requests? I've managed to implement a dummy handler here that does what I
> want, but how to I let python handle the events?

It looks like the approach would be to release the interpreter lock and
call PyErr_CheckSignals(), and then reestablish the lock.  (Look at
operation_skel() in server.c on how to restore/save the lock).

Jason.

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> It looks like the approach would be to release the interpreter lock and
> call PyErr_CheckSignals(), and then reestablish the lock.  (Look at
> operation_skel() in server.c on how to restore/save the lock).

Okay, this has been done, easily. However, now that I think of it, it
might not be a solution at all:

a) I override signal A using signal.signal()
b) orb.run() gets called
c) Just before actually doing the run() I set a new handler for A that
would check PyErr_CheckSignals()

I just lost the original handler, no?

So what I have to do is either set a default handler for all signals that
in turns calls a specific handler for each signal (which I doubt exists in
Unix), or save all handlers that came in in a structure and call them
accordingly depending on what signal I actually got.

Am I lost?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Jason T. <ta...@li...>]

> a) I override signal A using signal.signal()
> b) orb.run() gets called
> c) Just before actually doing the run() I set a new handler for A that
> would check PyErr_CheckSignals()
> 
> I just lost the original handler, no?

I don't _think_ so.  From what I can see in signalmodule.c, when you set
a custom handler using signal.signal(), it stores the Python function in
an array (line 256 of signalmodule.c, v1.5.2) after calling signal(2)
and setting the signal handler to the stub function signal_handler
(lines 249 and 245).

So when you call signal(2) yourself, you're just skipping the signal
module's stub function (signal_handler) in place of your own, both of
which will call PyErr_CheckSignals (line 142).  PyErr_CheckSignals loops
through that array (lines 628-644) and calls the Python functions that
were set using signal.signal().

So basically your stub function will have to reimplement what
signalmodule's signal_handler does, the most important of which (from
what I can tell) is lines 140 and 141.

Jason.

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> So basically your stub function will have to reimplement what
> signalmodule's signal_handler does, the most important of which (from
> what I can tell) is lines 140 and 141.

Almost fixed.. still looking into a minor issue but it sorta works. I'll
submit as soon!

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> I don't _think_ so.  From what I can see in signalmodule.c, when you set
> a custom handler using signal.signal(), it stores the Python function in
> an array (line 256 of signalmodule.c, v1.5.2) after calling signal(2)
> and setting the signal handler to the stub function signal_handler
> (lines 249 and 245).

It does, but AFAICS Handlers is opaque (declared as static) and can't be
accessed by external modules. So we're hitched because we can't set
tripped.

I'm wondering if we can use PyOS_getsig() and call the signal manually.
I'm checking.

> So when you call signal(2) yourself, you're just skipping the signal
> module's stub function (signal_handler) in place of your own, both of
> which will call PyErr_CheckSignals (line 142).  PyErr_CheckSignals loops
> through that array (lines 628-644) and calls the Python functions that
> were set using signal.signal().

Yeah, and poisoning the array seems to be the only thing I would need to
do, if everything wasn't declared static :-)

Still trying.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Mon, 4 Dec 2000, Christian Robottom Reis wrote:

> I'm wondering if we can use PyOS_getsig() and call the signal manually.
> I'm checking.

PyOS_getsig is Python 2.0 only, so I'm still wondering. I'm checking out
how pygtk does it, but my guess is it doesn't :-)

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311