Date: Tue, 14 Jul 1998 11:19:32 +0200 From: Stefan Eggers <seggers@semyam.dinoco.de> To: "Allen Smith" <easmith@beatrice.rutgers.edu> Cc: freebsd-hackers@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: Best means of telling if a proc is still around? Message-ID: <199807140919.LAA07274@semyam.dinoco.de> In-Reply-To: Your message of "Mon, 13 Jul 1998 19:48:44 EDT." <9807131948.ZM9979@beatrice.rutgers.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Use at_exit(9) to know when it exits. If it is important to you an > > at_exec(9) might be needed, too. The latter does not exist, yet. > mean doing a full-scale interpretation of what the system call is > doing at the time of the call, which is likely to be a duplication of > the stuff happening later. I suppose I could do an at_exit call at > each such system call, but that's going to result in a definite slowdown. No, you call it the first time you get called. Then you are on the list of things wanting to know about process exits and get a callback every time a process exits. At least that's what the -stable man page says. ;-) If that's too much overhead I think you can introduce a new type of service a la at_exit(9) w/o too much work but this time you don't hang it on a global list but add a local list to the process structure. Then you only get callbacks for the processes where you explicitly requested it and the only overhead for exiting non-affected processes is a test for this list to be empty if done the way I think it should work and a few (four on x86 I suppose) bytes. > Yeah, I know, I'm being a perfectionist - this combination isn't > _that_ likely to happen (indeed, I'm not sure if there are any > circumstances in which it _can_ happen currently) - but I'd prefer to Sure. That's probably the reason why you are willing to implement such a process local at_proc_exit(9). ;-) If you want very low overhead I think that's the only reasonable way to do it. With storing the PID you might get confused with a later existing process with the same PID and searching the process won't make the overhead lower. Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807140919.LAA07274>