Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Nov 1998 22:00:16 -0800
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        Luoqi Chen <luoqi@watermarkgroup.com>, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, jau@jau.tmt.tele.fi
Subject:   Re: question about getsid()
Message-ID:  <199811060600.WAA16417@salsa.gv.tsc.tdk.com>
In-Reply-To: Luoqi Chen <luoqi@watermarkgroup.com> "Re: question about getsid()" (Oct 24,  2:44am)

next in thread | previous in thread | raw e-mail | index | archive | help
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 losts 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.

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.

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.

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?199811060600.WAA16417>