Skip Menu |

This queue is for tickets about the Tk CPAN distribution.

Report information
The Basics
Id: 35033
Status: open
Worked: 25 min
Priority: 0/
Queue: Tk

People
Owner: Nobody in particular
Requestors: elmex [...] ta-sa.org
rt.cpan.org [...] plan9.de
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 804.028
Fixed in: (no value)



Subject: Tk::fileevent clears all handlers, not just the requested one
The following program: #!/usr/bin/perl use Tk; open my $fh, "+>/tmp/tktest" or die; my $mw = new MainWindow; $mw->fileevent ($fh, readable => "1"); $mw->fileevent ($fh, writable => "2"); warn $mw->fileevent ($fh, "readable"); warn $mw->fileevent ($fh, "writable"); $mw->fileevent ($fh, readable => ""); warn $mw->fileevent ($fh, "readable"); warn $mw->fileevent ($fh, "writable"); Outputs: Tk::Callback=SCALAR(0xa51950) at /tmp/tk.pl line 11. Tk::Callback=SCALAR(0x9230c0) at /tmp/tk.pl line 12. Warning: something's wrong at /tmp/tk.pl line 14. Warning: something's wrong at /tmp/tk.pl line 15. i.e. the "writable" handle gets cleared errornously, contrary to documentation, which explicitly states that readavlke and writable event handlers can be deleted seperately.
When I try this as workaround within a called fileevent handler, I get segfaults: my $r = $mw->fileevent ($self->{fh}, "readable"); my $w = $mw->fileevent ($self->{fh}, "writable"); $r = "" if $self->{poll} =~ /r/i; $w = "" if $self->{poll} =~ /w/i; $mw->fileevent ($self->{fh}, readable => $r); $mw->fileevent ($self->{fh}, writable => $w); Something is rotten here.
When I play around a lot, I sometimes don't get segfaults, but after I set the handlers to the values returned by fileevent and ask fort he handlers again, they have both been cleared again.
The subject line is a correct explanation of what happens. In the perl code the 'sub filevent' looks at return from XS call to handler. If it isn't true then it untie-s the file handle which in turn frees up the other handlers and leaves the references you saved in the workround pointing at nothing. What I think should happen is that the XS code should in the 3-arg case return NOT the callback it created (if any) as it does now, but rather the "mask" of active handlers. If the mask is zero then the untie is correct. It did not help diagnosis that your example does $mainwindow->fileevent($fh,'readable',"1"); The "1" isn't a sane callback, I am still confused by why it seems to generate a viable callback object rather than complaining. Will try and fix that at the same time.
From: rt.cpan.org [...] plan9.de
[NI-S - Sat Dec 3 15:51:20 2005]: Show quoted text
> > It did not help diagnosis that your example does
I am sorry, but fortunately the problem happens regardless of the handler. (My actual usage uses a code reference). However, I *did* assume that "1" was a correct arguemnt, as the manpage uses strings for that argument and talks about "evaluating" it, as opposed to calling it. If the interface would use more perl-ish undef and cod references and "calling" I would not have assumed that a string is a valid callback. However, even when using code references, the function does not return the same callback originally used, and the value returned cannot be used to set the callback, which is potentially another problem. Thanks for looking into this! I use it in the "AnyEvent" module, which allows module auhtors to use file events etc. in Tk, Glib and Event-based programs.
In case my last entry sounded a bit off: I _am_ sorry that I complicated debugging by mixing two seperate issues, I just wanted to say why I did it, and that I didn't do it on purpose :)
Please try attached patch. This changes return from XS part of code so that untie should only happen when last handler is deleted.
Download patch
application/octet-stream 573b

Message body not shown because it is not plain text.

[NI-S - Thu Dec 29 08:04:11 2005]: Show quoted text
> > Please try attached patch. > This changes return from XS part of code so that untie > should only happen when last handler is deleted.
I checked it against my testcases, they work fine. I also removed the workaround I had for Tk in Net::FCP and am running a daemon with hundreds of simultaneous connections all on the Tk event loop for a few minutes now - works fine, too :) Thanks!
Subject: #16246 reappeared: Tk::fileevent clears all handlers, not just the requested one
Hi! Even though the bug #16246 was resolved once it seems to be still (or again?) in the recent Tk version. This is my testcase: http://www.ta-sa.org/files/txt/b7c669b2ff74c8bfb3c57ee9c94e94f9.txt The 'READABLE' event is never detected, even though there is data waiting.
On Mon Apr 14 17:17:33 2008, ELMEX wrote: Show quoted text
> Hi! > > Even though the bug #16246 was resolved once it seems to be still (or > again?) > in the recent Tk version. > > This is my testcase: > http://www.ta-sa.org/files/txt/b7c669b2ff74c8bfb3c57ee9c94e94f9.txt > > The 'READABLE' event is never detected, even though there > is data waiting.
The patch was never applied. Does http://rt.cpan.org/Ticket/Attachment/150276/46775/patch still works for you with Tk804.028? Regards, Slaven
On Fri Sep 12 18:08:04 2008, SREZIC wrote: Show quoted text
> On Mon Apr 14 17:17:33 2008, ELMEX wrote:
> > Hi! > > > > Even though the bug #16246 was resolved once it seems to be still (or > > again?) > > in the recent Tk version. > > > > This is my testcase: > > http://www.ta-sa.org/files/txt/b7c669b2ff74c8bfb3c57ee9c94e94f9.txt > > > > The 'READABLE' event is never detected, even though there > > is data waiting.
> > The patch was never applied. Does > http://rt.cpan.org/Ticket/Attachment/150276/46775/patch > still works for you with Tk804.028? >
Unfortunately the patch makes t/leak.t fail now. Obviously the introduction of using newSViv() now created a memory leak. Need some additional investigation if and how this could be fixed. Regards, Slaven