sybperl-l Archive

From: Michael Peppler <mpeppler at MBAY dot NET>
Subject: Re: Off-topic: Perl Question
Date: Jan 15 1998 5:44PM

Tim_Green@mercer.com wrote:
> 
> >Tim_Green@mercer.com wrote:
> >>      So, I've got couple questions:
> >>
> >>      1.  In the code below extracted from the perlipc man page, can someone
> >>      explain the relationship between the for loop, the reaper function and
> >>      the $WAITEDPID variable?  Why must $waitedpid be in the for loop's
> >>      condition?
> >
> >I am not a TCP/IP specialist, but I would guess that the loop could be written:
> >
> >for ( $waitpid=0
> >      ($paddr = accept(Client,Server));
> >      $waitedpid = 0, close Client)
> >   {
> >      my($port,$iaddr) = sockaddr_in($paddr);
> >
> >ie skip the $waitpid condition in the for(), and forget about the if($waitpid)
> >in the body of the loop.
> >
> >In my opinion this should work fine.
> 
>      If I remember correctly (and I might not), I tried this when I
>      originally wrote the server (with perl 5.003).  It didn't work.  At
>      the time I hadn't a clue why, but I've since come to think it's
>      because the accept() function call will return with an undefined
>      socket if the application receives a signal.

Right - probably with a 'interupted system call' errno.


>      But what I don't understand is why the for loop needs to be coupled
>      with a reference to $waitedpid at all.  Why not just a 'while accept()
>      next if not defined($paddr)' construct?

Well, you'd have to write it

while(1) {
    $paddr = accept(...)
    next unless $paddr;
}

Now that I think of it the way the for loop is written it will 
exit if accept() returns undef (ie on error) and the error is NOT
SIGCHLD. That's probably the reason for coupling the $waitpid variable
with the for() loop.


> 
>      Anyway, thanks for the reply.  If you're curious what this is all about, I
>      wrote a server with sybperl to receive messages sent from my Sybase server
>      using Sybase's syb_sendmsg function.  We use it to run unix processes,
>      eliminating our need for an Open Server application.  Couldn't have done it
>      without Sybperl.

Cool.

(Of course with 11.5's extended stored procs this becomes easier
without external tools such as sybperl...)

Michael
--
Michael Peppler       -||-  Data Migrations Inc.
mpeppler@datamig.com  -||-  http://www.mbay.net/~mpeppler