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

In reply to IO::Multiplex and tied handles? by oldtomas

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.