Gtk::io patch

[Paolo Molaro <lupus ximian com>]

Forgot to send to the list...

lupus

-- 
-----------------------------------------------------------------
lupus debian org                                     debian/rules
lupus ximian com                             Monkeys do it better

--- Begin Message ---

• From: Paolo Molaro <lupus ximian com>
• To: Jim Edwards <jedwards inmet gov br>
• Subject: Re: Gtk::io patch
• Date: Fri, 13 Jul 2001 18:21:10 +0200

On 07/13/01 Jim Edwards wrote:

On 07/13/01 Jim Edwards wrote:

It seems like I´m talking to myself on this list lately.

Dude, maybe people are busy.
If you need around the clock support I'm sure some company
is willing to accept your money ;-)

I never asked for it, but I´ve been the only poster in two weeks.  I´m not
as worried about my questions not being answered as I am about commiting to
a tool that doesn´t have much momentum for continued development.  I would
have thought this tool would generate more interest than I´m seeing.

Well, if you have a look at the mailing list archive for last year,
you'll see that July is a very slow month for gtk-perl:-)
And you'll see also that traffic on this list has more than doubled since
last year: it's not bad as momentum in my book.
If you want more traffic I can easily send you the spam that I
get as list admin:-) Seriously, just wait a couple of days at
least before complaining you didn't get a reply (especially
if the question relates to the core of the Gtk module).
I try to reply as time permits, sometimes just a few minutes/hours
after a request, sometimes a few days (and maybe sometimes I
forget altogether about it:-).

Here is a simple patch that allows one to modify the timeout using
$Gtk::io::timeout.

First, use the -u option with diff, as it makes the output actually
readable.

use strict;

3,5c4,8
< my %pending = ();
< my $sweepid;
< my $timeout = 2;
---

use vars qw(%pending $sweepid $timeout);
BEGIN{
  %pending = ();
  $timeout = 2;
}

This approach exposes too much details about the implementation.
%pending I don't think needs to be exposed (but see later).
timeout is best handled with a sub timeout {} as described in the
IO::Socket manpage (ie a setter/getter method). This means that
once you created an IO::Socket::INET, for example, and rebless it to
Gtk::io::INET, you can just use:
        
        $socket->timeout (NEW_TIMEOUT);

as you would do with any other socket. You can just have it change
the global setting, but you'll get extra points if you'll make
the setting per-socket.

As for pending, it would be nice to have a couple of extra methods to
query if there is some action pending on the socket or to remove
a request.

sub is_pending {
        my ($socket, $cond) = @_;
        # $cond can be 'read' or 'write', if not given checks for both
        ...
        # returns the condition pending (again, read, write or both)
        # returns undef if not pending
}

sub cancel_request {
        my ($socket, $cond) = @_;
        # again, $cond is optional and works as above
}

lupus

-- 
-----------------------------------------------------------------
lupus debian org                                     debian/rules
lupus ximian com                             Monkeys do it better

--- End Message ---