Date: Fri, 5 Mar 1999 03:54:13 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jplevyak@inktomi.com (John Plevyak) Cc: tlambert@primenet.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads Message-ID: <199903050354.UAA25677@usr01.primenet.com> In-Reply-To: <19990303120101.A21432@proxydev.inktomi.com> from "John Plevyak" at Mar 3, 99 12:01:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think you can do this by recursing on the peers in the middle > > of handling the kill before you pass it to the trampoline (then > > it's too late). > > Why is it too late after that? In the patch I did the wait in exit1() > right after the 'kill' of the peers. It's too late if you've gone to user space with the signal, because it's an untrappable signal. That's the trampoline I was referring to. > The peers signal when they take themselves off the list > farther down in exit1, after the fdfree() call which > can result in the close and which would benefit from > having the p_leader still around. That's exactly the right way to do it, if you have to do it. > > Really, the thread specific data needs to be seperated from the > > proc struct; that is, the p->p_leader->foo should become meaningless. > > > > Basically, the litany on this is "everything that can differ between > > threads". > > You are very right. In the short term it might be best to > separate the parts of 'struct proc' which are thread specific > from those which are process specific. The process specific > parts can then always be accessed via 'p->p_leader' which > would amount to 't->t_proc' when at some future time these > two structures can be unwoven. Right. Such a structure is essentially identical in content to an async call context for an async call gate, BTW. 8-). > > I think the POSIX semantics, since they predate threads, can be > > reasonably interpreted either way. > > > > However, the use that you described seemed to want to scope file > > descriptors to a particular thread, such that a thread exit would > > result in the close. I don't think this is reasonable (the descriptor > > space is shared between all threads in a process). The only way > > to reasonably achieve such scoping is pthread_cleanup_push(). > > Actually, the opposite. What I would like is for file locks > to have process scope so that (for example) one thread could > open the file, a second could take out the lock, and a third > could close it, and the lock would be released. Currently > the lock is left hanging past when the process exits. Ah. OK, I was turned around from the desired semantics. I actually think that relying on the unlock as a side effect of the close is probably bad form. But I understand how it could come abut from a strict reading of POSIX. > I understand that generally signalling and threads is a bit messed up, > but I (somewhat urgently) have to solve the smaller problem of file > locking being broken for programs which use kernel threads. In any case, > FreeBSD should not be leaving the lock lying around past when the > process/thread which originated it died. That is clearly a bug. Strongly agreed. > I would like to get some patch into the FreeBSD source since > this is going to be an issue for production sites which would likely > prefer a 'blessed' solution rather than my personal patch. Don't look at me, I'm a heretic. I could curse you, if you think that'd help. 8-). > There are a number of possible solutions including the patch I proposed, > using a seperate id (rpid), adding additional bookkeeping to the > open fds vector etc. That's wouldn't actually work, unless the code believed you when you lied about the local PID (which it wouldn't), since it is different per thread in a "process" in the rfork implementation. Catch-22. You'd have to go forward on the proc/thread struct split. > However, I was hoping that by keeping the p_leader around, we could > use it as the 'process' and migrate to a model of seperate threads > and processes. That is what I am proposing. You might be able to get someone to commit this, at least as a short term soloution to the problem. It would get you over the "blessed" hump so you can concentrate on more pressing issues. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199903050354.UAA25677>