Hello Danny,
Wow, thank you for the speedy reply and the suggestions. I've been searching 
the Asterisk Mac community (including the voip-info wiki and astmasters.org) 
for some time and have been reading the man pages on "alarm" and how 
STDIN/OUT are handled both on linux and mac and couldn't come up with any 
reason that the code should behave differently.

I was thinking of trying a fork instead of the alarm but figured at a lower 
level the alarm was essentially doing the same thing.

Although very simplified, the perl code essentially looks like this:

    alarm(3);
    $fhO = \*STDOUT if (!$fhO);
    select ((select ($fhO), $| = 1)[0]);
    print $fhO "$command\n";
    $fhI = \*STDIN if (!$fhI);
    $response = <$fhI> || '200 result=-1 (noresponse)';
    chomp($response);
    $timeleft = alarm(0);

On linux the handleAlarm routine runs and finishes without a problem and 
when the user finishes recording and presses the # key, then the line 
$response = <$fhI> continues.  On the Mac, as soon as the alarm goes off 
$response gets '200 result=-1 (noresponse)'.  If I comment out the alarm(3), 
then it works.  It's so simple on the Perl side that I now think the problem 
must be in the Asterisk C code.

Thanks again,
Chris

"Danny Hembree" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> There is no difference between signals in Linux and signals in OSX, they
> behave the same. However, the way the processes setup may differ. There
> is an OSX asterisk version that should have this sorted out for you.
> There is a lot of help here:
>
> http://www.voip-info.org/tiki-index.php?page=Asterisk%20MacOSX%20Support
>
> On Tue, 2006-01-10 at 08:32, Chris wrote:
>> Hello,
>> I'm pretty much a newbie when it comes to Mac OS X so go easy on me.  I 
>> have
>> a Perl applicaton that communicates with the Asterisk VoIP phone system
>> through AGI (Asterisk Gateway Interface) very similar to CGI.  Asterisk
>> starts my perl application and the two communicate over STDIN and STDOUT
>> file handles.   When the user on the phone presses the # key my AGI perl
>> application is suppose to start recording what the users says until they
>> press # again.  The way this works, is the perl applications writes the
>> RECORD command to STDOUT and Asterisk starts to record and then the perl
>> program waits on STDIN for the response which would be the # key when the
>> user presses it.  I call the "alarm(3)" perl command (having set 
>> $SIG{ALRM}
>> = \&handleAlarm; earlier) before issuing the RECORD command to have perl
>> call my handleAlarm() routine to perform some tasks three seconds after 
>> the
>> recording starts (like check that the file actually has some sound and to
>> notify others that a messages is currently being recorded).
>
> There are several ways to fork a child process and the way Linux and BSD
> do this has minor variations. The way that it is forked determines
> whether the parent intercepts a signal or passes it to the child. The
> wait mask likewise varies between the OS's. Reading the manual pages
> over and over and experimentation is the only way I've ever gotten these
> things to work. In principal, the wait returns an integer, by masking
> the proper bits one can determine what broke the wait, then decide to
> continue waiting or exit.
>
>>
>> We've been using this application on a Linux machine for over a year and
>> recently I tried to port the whole thing to a Macmini with OS X 10.3.
>> Almost everything works great except, when the alarm goes off the wait on
>> STDIN stops prematurly before Asterisk has actually stopped recording. 
>> If I
>> comment out the alarm command the wait on STDIN works fine.
>>
>> I've posted this already in the Asterisk and AstMasters mailing list but 
>> I
>> think it may be more perl related then Asterisk related and having 
>> something
>> to do wtih the whole alarm subsystem on Mac OS X vs Linux.  Asterisk is
>> writen in straight C so perhaps they are both using the same alarm timer.
>> Any thoughts or suggestions would be greatly appreciated because I'm
>> stumped.
>>
>> Thanks,
>> Chris
>>
>>
> 


Reply via email to