Date: Fri, 6 Nov 1998 16:14:03 +0200 (EET) From: "Jukka A. Ukkonen" <jau@jau.tmt.tele.fi> To: Don.Lewis@tsc.tdk.com (Don Lewis) Cc: luoqi@watermarkgroup.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG Subject: Re: question about getsid() Message-ID: <199811061414.QAA02132@jau.tmt.tele.fi> In-Reply-To: <199811060600.WAA16417@salsa.gv.tsc.tdk.com> from "Don Lewis" at Nov 5, 98 10:00:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Don Lewis: > > On Oct 24, 2:44am, Luoqi Chen wrote: > } Subject: Re: question about getsid() > > } > getsid() needs to verify s_leader is not NULL before dereferencing it, > } > but what should getsid() return if there is no session leader? > } > > } If the session leader is gone, the session looses the ability to acquire > } a controlling terminal, which is the sole purpose of its existence. > } This session should be disbanded, and member process groups join session 0. > > I can see three possible implementations. The first two implementations > are literally what you describe. > > In the first, all the process groups need to be visited and any that > reference this session need have their pg_session pointer changed to > point to session0, and the reference counts updated. This could be > expensive if there are a lot of process groups. This would be all too costly in the sense of CPU time. > In the second implementation, all of the process groups that belong to > a session would be linked together and hung off the session structure. > When the session leader exits, it would only be necessary to traverse > this short list. This is more expensive in terms of memory consumption, > but it would be possible to eliminate the session reference count. > Another disadvantage would be the expense of maintaining the session0 > process group list, since this list could be quite long. Also this alternative would take a lot of unnecessary work that can be avoided. And as you said, the memory is also a resource which should be saved if possible. So, I do not think this is either the way to go. > The simple but hackish thing to do would be to change getsid() to > return session0.s_leader->p_pid if p->p_pgrp->pg_session->s_leader > is NULL, and reclaim the abandoned session when all the process groups > that reference it are gone. Basically this is the ideal thing, because the system does no extra fiddling with anything when it is not absolutely necessary. I really do not remember whether POSIX actually requires the system to let the processes in a session to know that their original session leader is gone by getsid() returning 0, but I take it that you have checked this. I tried to seek a document where this rather odd behavior has been defined, but I have not found anything containing a reference to such behavior. All of the definitions of getsid() I have been able to find have been virtually equal to http://www.opengroup.org/onlinepubs/7908799/xsh/getsid.html So, before deciding upon implementation I would really like to find all the facts first. If you have a document where the odd getsid() behavior has been defined, please, please, quote the text, or point me to the paper where it is stated. As I said already earlier, it might be sometimes preferable to let the notion of session double also as an indication of processes being related in addition to only limiting allocation of a new ctty. If the POSIX rules really require an indication of the session leader being gone as a 0 return value from getsid(), I do not understand what end does this serve. As long as ctty allocation is considered any process should be quite content knowing whether it is a process leader or not. If the POSIX intention has been only to let the caller to know it cannot allocate a ctty, a test (pid != getsid(pid)) would have sufficed just fine. Otherwise returning the original session ID would carry much more information. Cheers, // jau .--- ..- -.- -.- .- .- .-.-.- ..- -.- -.- --- -. . -. / Jukka A. Ukkonen, Internet Services R&D / Sonera Ltd. /__ M.Sc. (sw-eng & cs) (Phone) +358-2040-4025 / Internet: Jukka.Ukkonen@sonera.fi (Fax) +358-2040-64724 / Internet: jau@iki.fi (Mobile) +358-400-606671 v Internet: ukkonen@nic.funet.fi (Home&Fax) +358-9-6215280 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?199811061414.QAA02132>