oldtomas has asked for the wisdom of the Perl Monks concerning the following question:

Dear Perl Monks,

This is a sequel to another question. Since it's another problem, I decided to post as a new question.

I'm trying to build something around IO::Multiplex (I refer to version 1.13, which seems to be current in CPAN.

Some of the file descriptors are actually SSL sockets (as provided by IO::Socket::SSL (I'm -- so far -- the client side).

Playing aroud with that, I see garbage coming out of the SSL sockets. Looking into IO::Multiplex.pm, I see (lines 572 and following, lots of elisions):

sub loop
{
  my $self = shift;
  my $heartbeat = shift;
  $self->{_endloop} = 0;

  while (!$self->{_endloop} && keys %{$self->{_fhs}}) {
    foreach my $k (keys %{$self->{_handles}}) {
      [...]
      # Is this descriptor ready for reading?
      if (fd_isset($rdready, $fh))
      {
        if ($self->{_fhs}{"$fh"}{listen}) {
          # It's a server socket, so a new connection is
          [...]
        } else {
          if ($self->is_udp($fh)) {
            [...]
          } else {
            $rv = &POSIX::read(fileno($fh), $data, BUFSIZ);
          }
          [...]
        }
      }  # end if readable
      next unless exists $self->{_fhs}{"$fh"};

      if (fd_isset($wrready, $fh)) {
        unless (length $self->{_fhs}{"$fh"}{outbuffer}) {
          [...]
        }
        $rv = &POSIX::write(fileno($fh),
                            $self->{_fhs}{"$fh"}{outbuffer},
                            length($self->{_fhs}{"$fh"}{outbuffer}));
          [...]
      }  # End if writeable
      next unless exists $self->{_fhs}{"$fh"};

    }  # End foreach $fh (...)

    $self->_checkTimeouts() if @{$self->{_timers}};

  } # End while(loop)
}

[download]

So far, it's standard select() ware. But look at those &POSIX::read and &POSIX::write. Aren't they bypassing the tied IO::Socket::SSL magic which encodes/decodes things between us and the net?

Now my first question: Is this a bug?

What's a bit diconcerting for me here is that IO::Multiplex does try to get along with SSL sockets. They are special-cased around line 585, trying to pay tribute to the fact that those sockets sometimes want to be read from or written to at seemingly unexpected times (to keep the underlying protocol flowing). So I might be overlooking something

The "fix" I'll try to attempt is, at IO::Multiplex::add to try to get the read & write functions out of the given handles and use those, like so

package IO::Multiplex;
[...]
sub add {
   [...]
   $self->{_fhs}{"$fh"}{writefun} = $fh->can('syswrite');
   $self->{_fhs}{"$fh"}{readfun} = $fh->can('sysread');
   [...]
}

[download]

and then use these instead of POSIX::write and POSIX::read.

Now my second question: does this make sense? Is there another, better way?

And the third one. Is it a bug in IO::Multiplex? Shall I report it?

Thanks for any help, consolation, inspiration

Replies are listed 'Best First'.
Re: IO::Multiplex and tied handles?
by oldtomas (Novice) on May 28, 2012 at 07:31 UTC

    After some experimenting -- no, this doesn't work. "Freezing" the write function before the tie() won't help, since the dispatch is happening later, at call time, depending of the then current ties, as can be seen in

    #!/usr/bin/perl
#
# tying knots: how to override a tied filehandle and still access its 
+guts?
use IO::Handle;
use Data::Dumper;

package Hahandle;
use base qw(Tie::Handle);

sub TIEHANDLE {
  my ($class, $ll) = @_; # ll: the "lower level ref"
  return bless {
    _ll => $ll,
    _llwrite => $ll->can('syswrite')
  }, $class;
}

sub WRITE {
  my($self, $buf, $len, $offs) = @_;
  $buf =~ s/(\w+)/$1 $1/g; # quite dirty
  syswrite(STDOUT, $buf, length($buf), $offs);
}

sub llwrite {
  my $self = shift;
  $self->{_llwrite}($self->{_ll}, @_);
}

################

package main;

my $out = IO::Handle->new_from_fd(STDOUT, "w");
$out->write("(0) bong!\n");
my $wr = $out->can('syswrite');
tie(*$out, 'Hahandle', $out);
$out->write("(1) bong!\n");
&$wr($out, "(2) bong!\n");

    [download]

    which yields

    (0) bong!
(1 1) bong bong!
(2 2) bong bong!

    [download]

    Gaah. Of course, I might do fdopen before tie()ing, but I guess I'd lose the original tie. Help. Is there a way to "stack ties"?

[reply]
[d/l]
[select]

      There seems to exist a solution (phew)

      Handwaving

      Very lightly tested, and it might depend heavily on the details of the tied handle, but this approach already showed some "signs of life"

      The gist is, you have to stash away the tied object before re-tieing it, and then delegate to its methods when it comes to reading and writing.

      Show me the code

      In the case of IO::Multiplex and IO::Socket::SSL that means:

      Stash away the tied object

      In IO::Multiplex's add method, stash away the tied object before it gets steamrolled by the new tie()

        sub add
  {
    [...]
    $self->{_fhs}{"$fh"}{oldtie} = tied(*$fh) if defined(tied(*$fh));
    $self->{_handles}{"$fh"} = $fh;
    tie *$fh, "IO::Multiplex::Handle", $self, $fh;
    return $fh;
  }

      [download]

      Delegate read, write to the stashed-away object, fall back to POSIX::read and POSIX::write

      Somewhere in IO::Multiplex's loop method, replace the direct calls to POSIX::read resp. POSIX::write by those two code snippets: 
        $rv = ($self->{_fhs}{"$fh"}{oldtie})
    ? $self->{_fhs}{"$fh"}{oldtie}->READ($data, BUFSIZ)
    : &POSIX::read(fileno($fh), $data, BUFSIZ);

      [download]
      resp. 
        $rv = ($self->{_fhs}{"$fh"}{oldtie})
    ? $self->{_fhs}{"$fh"}{oldtie}->READ($data, BUFSIZ)
    : &POSIX::read(fileno($fh), $data, BUFSIZ);

      [download]

      Caveats

      This code is in the "I-tried-it-once-and-it-seemed-to-work" category. Use with care.

      Don't forget goggles and gloves.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom