Skip Menu |

This queue is for tickets about the Tk CPAN distribution.

Report information
The Basics
Id: 23879
Status: resolved
Priority: 0/
Queue: Tk

People
Owner: Nobody in particular
Requestors: MLEHMANN [...] cpan.org
sol0 [...] Lehigh.EDU
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 804.027
Fixed in: (no value)



Subject: Signals should wake Tk
Date: Tue, 09 Mar 2004 20:14:32 +0000
To: bug-tk [...] rt.cpan.org
From: Steve Lidie <sol0 [...] Lehigh.EDU>
On Mar 6, 2004, at 6:09 PM, Nick Ing-Simmons wrote: Show quoted text
> Steve Lidie <sol0@lehigh.edu> writes:
>> >> I suspect this is part of Perl's safe signal handling - the *operating >> system* signal isn't being delivered because perl isn't doing >> anything.
> > With perl5.8 and Tk we have doubly-safe signal handling ;-) > I think by default Tk delays signals till its event loop wakes up. > This was a fix for older perls, it may too safe now. > >
>> Once you wave the cursor over a window an *X11 signal* is raised and >> the Tk event loop restarts. >> So, one way to have an alien process alert an idle Tk program is to >> never have it idle - i.e. keep the event loop active. >> >> So, alien process does "kill USR2, ptk-process", and ptk-process does: >> >> $SIG{USR2} = sub { &synchronize }; >> $mw->repeat( 10_000 => sub { $mw->idletasks } ); >> >> A poll every 10 seconds works for my tape device code, you'll have to >> find your tradeoff between responsiveness and efficiency. Now to see >> if there's a more clever way ...
> > Now that perl has safe signals, I guess Tk could notice that > a signal is pending and dispatch it when OS breaks into its > select() call. >
If youd he arrange it that would be wonderful, obviating my hack ...
Subject: Tk makes catching async signals impossible
While in Tk's mainloop, catching signals (via %SIG) is impossible, as Tk does not do a signal check after select returns, so the signal will be executed only when perl regains control, which can be never. The solution would likely be to PERL_ASYNC_CHECK when select returns with EINTR.
On Sun Dec 10 19:54:21 2006, MLEHMANN wrote: Show quoted text
> While in Tk's mainloop, catching signals (via %SIG) is impossible, as Tk > does not do a signal check after select returns, so the signal will be > executed only when perl regains control, which can be never. > > The solution would likely be to PERL_ASYNC_CHECK when select returns > with EINTR.
I think you don't like this workaround? $mw->repeat(50,sub{}); Well, I'll look into it... Regards, Slaven
CC: MLEHMANN [...] cpan.org
Subject: Re: [rt.cpan.org #23879] Tk makes catching async signals impossible
Date: Sat, 16 Dec 2006 04:24:12 +0100
To: Slaven_Rezic via RT <bug-Tk [...] rt.cpan.org>
From: Marc Lehmann <schmorp [...] schmorp.de>
On Fri, Dec 15, 2006 at 09:38:53PM -0500, Slaven_Rezic via RT <bug-Tk@rt.cpan.org> wrote: Show quoted text
> On Sun Dec 10 19:54:21 2006, MLEHMANN wrote:
> > The solution would likely be to PERL_ASYNC_CHECK when select returns > > with EINTR.
> > I think you don't like this workaround?
Oh, I like workarounds like that (and implemented something very similar already), but as I do not use Tk personally, I have no code that needs it. However, ince its fixed, I can re-enable the test in AynEvent again and AnyEvent moduels will miraciously start working (wlel, they already do work, you just have to create some events, I guess). Show quoted text
> Well, I'll look into it...
Thanks, thats wonderful, but its not time critical for sure :) -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
I believe this is solved in Tk804.028. Regards, Slaven