Will python ever have signalhandlers in threads?

Op 2004-11-09, Antoon Pardon schreef <ap*****@forel. vub.ac.be>:

I have had a look at the signal module and the example
and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

Well I guess that the lack of response means the anser is:

Not likely.
Pity!

--
Antoon Pardon

Antoon Pardon wrote:

Op 2004-11-09, Antoon Pardon schreef <ap*****@forel. vub.ac.be>:

I have had a look at the signal module and the example
and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

Well I guess that the lack of response means the anser is:

Not likely.

Sorry that I don't have time to go through the code you mention, but recently
for ipython I had to deal with signal handling in threads. You can look in
IPython's Shell.py for the hacks I ended up using, if you care.

The gist of it is this function, which gets installed into a gtk/WX timer:

def runcode(self):
"""Execute a code object.

Multithreaded wrapper around IPython's runcode()."""

# lock thread-protected stuff
self.ready.acqu ire()

# Install sigint handler
signal.signal(s ignal.SIGINT, sigint_handler)

if self._kill:
print >>Term.cout, 'Closing threads...',
Term.cout.flush ()
for tokill in self.on_kill:
tokill()
print >>Term.cout, 'Done.'

# Run pending code by calling parent class
if self.code_to_ru n is not None:
self.ready.noti fy()
self.parent_run code(self.code_ to_run)
# Flush out code object which has been run
self.code_to_ru n = None

# We're done with thread-protected variables
self.ready.rele ase()
# This MUST return true for gtk threading to work
return True

As you see, I ended up installing the handler on *every* invocation of the
function, after taking a lock. I couldn't find how to assign the handler to
the thread, so this was my brute-force approach.

This is incredibly ugly, and there may be a better solution. But in this
particular case, the hack works and the penalty is not noticeable to end users.

Best,

f

> I have had a look at the signal module and the example

and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

I think acording to the Posix Thread specs, signals are only delevered to
the process and never to threads... I could be wrong though...

--
damjan

On 9 Nov 2004 11:56:32 GMT, Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

I have had a look at the signal module and the example
and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

Do you have a specific use in mind? E.g., I believe there are things you can
do in the main thread that won't work in others, and other things
can be solved by appropriate communication between threads, etc.,
but without more clues it's hard to discuss it. I didn't look at
the example because I don't want to guess what "similar code" you
really are interested in ;-)

Regards,
Bengt Richter

Fernando,

Just curious, does 'gtk/WX' in your message below mean wxPython?

If so, does this signal handling code actually work with wxPython?

/Jean Brouwers
In article <ma************ *************** ***********@pyt hon.org>,
Fernando Perez <fp*******@yaho o.com> wrote:

Antoon Pardon wrote:

Op 2004-11-09, Antoon Pardon schreef <ap*****@forel. vub.ac.be>:

I have had a look at the signal module and the example
and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

Well I guess that the lack of response means the anser is:

Not likely.

Sorry that I don't have time to go through the code you mention, but recently
for ipython I had to deal with signal handling in threads. You can look in
IPython's Shell.py for the hacks I ended up using, if you care.

The gist of it is this function, which gets installed into a gtk/WX timer:

def runcode(self):
"""Execute a code object.

Multithreaded wrapper around IPython's runcode()."""

# lock thread-protected stuff
self.ready.acqu ire()

# Install sigint handler
signal.signal(s ignal.SIGINT, sigint_handler)

if self._kill:
print >>Term.cout, 'Closing threads...',
Term.cout.flush ()
for tokill in self.on_kill:
tokill()
print >>Term.cout, 'Done.'

# Run pending code by calling parent class
if self.code_to_ru n is not None:
self.ready.noti fy()
self.parent_run code(self.code_ to_run)
# Flush out code object which has been run
self.code_to_ru n = None

# We're done with thread-protected variables
self.ready.rele ase()
# This MUST return true for gtk threading to work
return True

As you see, I ended up installing the handler on *every* invocation of the
function, after taking a lock. I couldn't find how to assign the handler to
the thread, so this was my brute-force approach.

This is incredibly ugly, and there may be a better solution. But in this
particular case, the hack works and the penalty is not noticeable to end users.

Best,

f

Jean Brouwers wrote:

Fernando,

Just curious, does 'gtk/WX' in your message below mean wxPython?
Yes.
If so, does this signal handling code actually work with wxPython?>

It does, but not in a generic manner: this is code for ipython to support
matplotlib's WX backend in an interactive shell. It allows you to type into
ipython plotting commands which cause matplotlib to open a WX plotting window,
and the interactive terminal continues to function. You can have multiple WX
plotting windows open, and the command line keeps on chugging.

But this relies on a special collaborative hack between matplotlib and ipython.
matplotlib, in its WX and GTK backends (Tk doesn't need this) has a special
flag to indicate who is in control of the mainloop. In standalone scripts,
everything works in the typical manner. But if ipython comes in, it will set
this flag, telling matplotlib to keep off the mainoop.

It's pretty hackish, but it works in practice pretty well.

here's the relevant matplotlib WX code (trimmed of docstring):

def show():

for figwin in Gcf.get_all_fig _managers():
figwin.frame.Sh ow()
figwin.canvas.r ealize()
figwin.canvas.d raw()

if show._needmain and not matplotlib.is_i nteractive():
wxapp.MainLoop( )
show._needmain = False
show._needmain = True

When ipython starts up, it sets show._needmain to False, so that the Mainloop()
call is never made. You can look at the whole code from ipython if you wish,
it's in IPython/Shell.py.

best,

f

Quite interesting, I'll check the Shell.py for more details. Thank you.

/Jean Brouwers

In article <ma************ *************** ***********@pyt hon.org>,
Fernando Perez <fp*******@yaho o.com> wrote:

Jean Brouwers wrote:

Fernando,

Just curious, does 'gtk/WX' in your message below mean wxPython?

Yes.

If so, does this signal handling code actually work with wxPython?>

It does, but not in a generic manner: this is code for ipython to support
matplotlib's WX backend in an interactive shell. It allows you to type into
ipython plotting commands which cause matplotlib to open a WX plotting window,
and the interactive terminal continues to function. You can have multiple WX
plotting windows open, and the command line keeps on chugging.

But this relies on a special collaborative hack between matplotlib and
ipython.
matplotlib, in its WX and GTK backends (Tk doesn't need this) has a special
flag to indicate who is in control of the mainloop. In standalone scripts,
everything works in the typical manner. But if ipython comes in, it will set
this flag, telling matplotlib to keep off the mainoop.

It's pretty hackish, but it works in practice pretty well.

here's the relevant matplotlib WX code (trimmed of docstring):

def show():

for figwin in Gcf.get_all_fig _managers():
figwin.frame.Sh ow()
figwin.canvas.r ealize()
figwin.canvas.d raw()

if show._needmain and not matplotlib.is_i nteractive():
wxapp.MainLoop( )
show._needmain = False
show._needmain = True

When ipython starts up, it sets show._needmain to False, so that the
Mainloop()
call is never made. You can look at the whole code from ipython if you wish,
it's in IPython/Shell.py.

best,

f

On 2004-11-12, Bengt Richter <bo**@oz.net> wrote:

On 9 Nov 2004 11:56:32 GMT, Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

I have had a look at the signal module and the example
and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

Do you have a specific use in mind?

Any code that can block/run for unbounded time (in extention code)
and you wish to interrupt after a certain time out.

One thing where it could be usefull is the Queue module.

AFAIU the Queue module doesn't block on a full/empty queue when
a timeout is specified but goes in a loop sleeping and periodically
checking whether place/items are available. With signals that
can be sent to a thread the queue could just set an alarm and
then block as if no timeout value was set and either unblock
when place/items are available or get signalled when the timeout
period is over.

--
Antoon Pardon

Antoon Pardon wrote:

AFAIU the Queue module doesn't block on a full/empty queue when
a timeout is specified but goes in a loop sleeping and periodically
checking whether place/items are available. With signals that
can be sent to a thread the queue could just set an alarm and
then block as if no timeout value was set and either unblock
when place/items are available or get signalled when the timeout
period is over.

I'm fairly sure that the Queue uses an internal Event
(or REvent?) to signal when space or a new item is
available, so I believe your description (and possibly
conclusion) above is wrong. There should be no
"periodical check", as that would imply polling. Check
the source if you're interested.

-Peter