From owner-freebsd-hackers Tue Jul 14 13:39:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11081 for freebsd-hackers-outgoing; Tue, 14 Jul 1998 13:39:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11076 for ; Tue, 14 Jul 1998 13:39:01 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id WAA06931; Tue, 14 Jul 1998 22:34:38 +0200 (MET DST) Received: from semyam.dinoco.de (semyam.dinoco.de [127.0.0.1]) by semyam.dinoco.de (8.8.8/8.8.8) with ESMTP id LAA07274; Tue, 14 Jul 1998 11:19:33 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199807140919.LAA07274@semyam.dinoco.de> To: "Allen Smith" cc: freebsd-hackers@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: Best means of telling if a proc is still around? In-reply-to: Your message of "Mon, 13 Jul 1998 19:48:44 EDT." <9807131948.ZM9979@beatrice.rutgers.edu> Date: Tue, 14 Jul 1998 11:19:32 +0200 From: Stefan Eggers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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