From: Don Burns (don_burns++at++peru.engr.sgi.com)
Date: 01/15/2001 09:49:33
Performer undoubtedly sets a signal trap that responds to SIGCHILD. As
most signal callbacks intended to receive a SIGCHILD, it probably calls
the waitpid() (or wait()) for you, such that when your waitpid() is called
the process has already been reaped. Further, there may be other layers
of children that are now out of your reach.
I would suggest a more modular approach to what you want to do. Write a
separate standalone process to control the player and communicate with
Performer via external shared memory. It doesn't sound like your player
program needs access to the scene graph or any of Performer's memory,
right?
-don
On Mon, 15 Jan 2001, Mark Evans wrote:
> I am using Performer 2.3 on Linux. I have a simple
> program that should start an audio or video player
> using a keypress.
> In the app callback I check if the specific key was
> pressed and start the auxiliary player via a fork()
> call.
> The problem is when I want to kill the program: also
> in the App callback I make a kill() call to the pid of
> the audio or video player, then a waitpid() call.
> The kill() call returns 0, which means it was
> succesfull, but the player is NOT stopped. Immediately
> after that I get a
> PF Notice: caught SIGCHILD ....
> message from Performer, and waitpid() reports there is
> NO such message as the one I had previously launched
> via fork() and killed via kill(). The player still
> plays the audio or video.
> Is my approach wrong? What do I have to do to stop the
> auxiliary program? Is it because of Performer 2.3,
> should I try Performer 2.4 for Linux?
>
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
This archive was generated by hypermail 2b29 : Mon Jan 15 2001 - 09:49:40 PST