Re: Re (tilly) 1: Segfault with Storable ( updated w/ code )

Thanks for the tip!

However what needs to be done, needs to be done... so do you by any change have a good suggestion as to writing perl code that reads a Storable object from socket, but returns an error status when you exceed the timeout without resorting to signals?

UPDATE actually, I tried this, and it still segfaults:

sub read
{
        my $socket = shift;
        my $timeout = shift || 60;

        return undef unless( _is_valid( $socket ) );

        my $hash;
        local $@ = '';
        my $select = IO::Select->new( $socket );
        while( $timeout-- ) {
                last unless _is_valid( $socket );
                if( $select->can_read( 1 ) ) {
                        eval{
                                $hash = fd_retrieve( $socket );
                        };
                        return $@ ? undef : $hash
                }
        }

        return undef;
}
[download]

Comment on Re: Re (tilly) 1: Segfault with Storable ( updated w/ code ) Download Code

Replies are listed 'Best First'.
Re (tilly) 3: Segfault with Storable by tilly (Archbishop) on Sep 28, 2001 at 07:12 UTC
Well, you can always write a method for it at each end. Just nfreeze it to a scalar, figure out how long it is, send a header, then send the object. The reading code needs to read the header, figure out the length of the object, and then read the object. The trick is getting the reading code to give up if it cannot get everything in the required time. At least two safe ways come to mind to do the trick. Both are a little heavy. One is to use a select (or IO::Select)/sysread loop to read character by character and die if you fail. If you write this correctly you can actually multiplex multiple loops. But note that you are now writing a Perl level loop for every character coming in - this is not the most efficient thing to do... The other is to put a process between you and the other end which you don't mind dying. You could launch it with IPC::Open2 with an argument saying how long it is going to live before dying, it sets up the alarm with an exit on read failure (unstable signal handling doesn't matter now since you want it to die), and it will process one object off of the pipe, echo it back to you, then die. You can now do a blocking read of that object, safe in the knowledge that the other end is going away. After it goes away you can reap it with wait or waitpid. Launching a process per object is extreme, but if the objects are very large it may be more efficient. UPDATE Response to your update. All that select will do is guarantee a single incoming byte. That is why you have to sysread single chars in a loop. You don't know that there will be more than that, and you don't want to block. And since you have to handle the read at a low-level, you can't punt to Storable's processing method. Which is why I said up front that you would want to write your own communication protocol at each end.	[reply]

Replies are listed 'Best First'.

Re (tilly) 3: Segfault with Storable
by tilly (Archbishop) on Sep 28, 2001 at 07:12 UTC

The trick is getting the reading code to give up if it cannot get everything in the required time. At least two safe ways come to mind to do the trick. Both are a little heavy.

One is to use a select (or IO::Select)/sysread loop to read character by character and die if you fail. If you write this correctly you can actually multiplex multiple loops. But note that you are now writing a Perl level loop for every character coming in - this is not the most efficient thing to do...

The other is to put a process between you and the other end which you don't mind dying. You could launch it with IPC::Open2 with an argument saying how long it is going to live before dying, it sets up the alarm with an exit on read failure (unstable signal handling doesn't matter now since you want it to die), and it will process one object off of the pipe, echo it back to you, then die. You can now do a blocking read of that object, safe in the knowledge that the other end is going away. After it goes away you can reap it with wait or waitpid. Launching a process per object is extreme, but if the objects are very large it may be more efficient.

UPDATE
Response to your update. All that select will do is guarantee a single incoming byte. That is why you have to sysread single chars in a loop. You don't know that there will be more than that, and you don't want to block. And since you have to handle the read at a low-level, you can't punt to Storable's processing method. Which is why I said up front that you would want to write your own communication protocol at each end.

[reply]