Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: programatic tool interaction

Your best bet is to implement your own code for spawning and controlling a child process; there is no standard method for obtaining the PID of a popen'ed process from the FD.

The normal way of handling this via popen() is to in fact use an intermediate parent program to spawn the child, and have the parent program terminate the child after waiting a bit. You actually end up with a similar situation if you implement your own wrapper instead of using popen(). In general, this is basically how servers supporting CGI plugins, like Apache, timeout CGIs which are "hung" or "taking too long".

As a practical matter, the popen() code uses an internal static list of structures indexed off a static global inaccessible outside of gen/ FreeBSD/popen.c in the Libc sources; the list is manipulated under the THREAD_LOCK lock.

If you elected to do so, you could take the Libc implementation and add to it, and link your program to it before linking to Libc, in order to get a function that would return the pid for a popen()'ed descriptor, e.g.:

	
	...rest of popen.c contents ....

	pid_t
	pgetpid(FILE *iop)
	{
        	struct pid *cur;
	        pid_t pid;

/*
* Find the appropriate file pointer and remove it from the list.
*/
THREAD_LOCK();
for (cur = pidlist; cur; cur = cur->next)
if (cur->fp == iop)
break;
if (cur == NULL) {
pid = (pid_t)-1;
} else {


pid = cur->pid;
}
THREAD_UNLOCK();

return (pid);
}

My own take on this is that I'd write my on wrapper; not only would it do exactly what I wanted, it'd do only what I wanted, and if needed, I could use a pty so that the program running as the child wouldn't know that it wasn't running on a terminal, and I'd have the output/input flushing semantics that you get on an interactive tty, so if someone screwed up the stdio buffering, or failed to understand pipes, or tried to use it with a program that expected to run on a tty, things would still work.

-- Terry


On Dec 22, 2005, at 11:58 AM, Caius wrote: 
Hi

I have a related question.

I am actually using popen to run some shell scripts from within an application. However sometimes these scripts hang and I would like to be able to kill the script after some amount of time. Otherwize, when I kill the parent application the script is still running and therefore the resources (sockets etc..) associated with the application dont get closed.

Is there some way of sending a kill signal to a processes started with popen()? pclose is no good as it waits for thhe child to exit.

Thanks
Caius

On 21 Dec 2005, at 12:32, Brian J. Landsberger wrote:

Kevin,

You may be able to use popen for this, Stevens covers this in sections 14.3 and 14.4 of Advanced Programming in the UNIX Environment (first revision). I suggest reading through Chapter 14 though.

Thanks,

Brian J. Landsberger
email@hidden
Cell: 206.658.5819



On Dec 21, 2005, at 12:08 PM, Kevin Packard wrote:

Please forgive me if this is not the appropriate list, but I've not been unable to google the answer, or find it in Apple's dev pages.

Is there any way to programatically interact with a UNIX tool from a Carbon app? sysctl() gives me a one-shot run, but I'd like to launch a tool, create some sort of a pipe to it, write to its stdin, and read from its stdout.

Can someone please point me to a method to do this (or tell me I'm insane)?

thanks,
--
Kevin Packard

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden

This email sent to email@hidden


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden

This email sent to email@hidden

--
Caius Howcroft
Mobile (UK): +44 779 203 0046
Mobile (US): +1   626 487 1202
Skype:  caiush

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden

This email sent to email@hidden 

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden

This email sent to email@hidden
References: 
 >programatic tool interaction (From: Kevin Packard <email@hidden>)
 >Re: programatic tool interaction (From: "Brian J. Landsberger" <email@hidden>)
 >Re: programatic tool interaction (From: Caius <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.