site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h6GlEnhHdUY09808ntnSlKrON7GYj3zk+xmFdbQsbV4IsWaDR5JMWIJx9mrFAbdIia9ShwtDh4Ru9yzzBwJfukFeGj+Mvq+y2HsLPE+QEm3EI5oNwam2axYFk0jbcC9ynvodhZp+hlAA34+CoBOzsrE9LdoqIpteHy0EGz9fGAs= The kernel's "permanent memory" is completely full of bits of the kernel, so wherever it might go that ain't it. After looking into it some more, I was going to try to avoid that approach anyway. It looks promising, but also not so much a viable short-term solution. So, even if the incoming connection does not have a pid associated with it (at the time that I need to know the pid), I do know the associated local port, and I can look at the existing listeners and find the one that corresponds, and I know the pid that created the listener (even if it is not the one that is calling accept). So, in some cases I'll have the correct pid/path, and in other cases I'll have just one value or neither. Not ideal, but it'll have to do until I can find a way to know about fork()'ing activity. -- Curtis Jones _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On 12/26/06, Michael Smith <drivers@mu.org> wrote: This email sent to site_archiver@lists.apple.com