On Thu, Aug 24, 2000 at 09:23:34AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 24 Aug 2000, Andi Kleen wrote:
> >
> > Wouldn't it make more sense to extend the current process group concept ?
> > A process could be in two groups, the thread group and the process group
> > with the pid of the session group leader.
>
> The problem is that I can certainly see a process group leader that is
> _also_ a "tgid leader".
>
> Basically, imagine any process group or session leader that wants to be
> threaded itself. Now there is a lot of confusion about what "-tgid" means,
> as "tgid == pgid" and thus obviously "-tgid == -pgid", making sys_kill()
> have a really hard time deciding which to kill.
Yes, the process would need to have two ancillary ids then (I actually
mentioned that in the original mail)
When the tids are chosen out of the same space as pids like you proposed
there would be no conflicts (because kill(-X) can be either a proces group
leader or a tid, but not both)
> > > gets updated at fork() and exit() so that we can easily walk every process
> > > in the process group list).
> >
> > POSIX wants to send the signal to the first thread in the group who
> > doesn't have it blocked.
> >
> > Several signals are special cased in POSIX, e.g. SIGSTOP, and need to
> > handled by all threads in the group.
>
> Right, which is why we probably do need the list for efficiency.
>
> Note that the "first thread that doesn't block it" decision is the really
> nasty one. If all threads have it blocked, we need to have it pending. But
> we can only have it pending for _one_ thread. I think POSIX allows this,
> but I'm not sure.
So put it into the signal_struct in this case. signal_struct would have
the same signal related fields as the processes, a mask and a pending
flag. when it fires you walk the tid ring again.
>
> > For good behaviour you need a shared sigprocmask(). (I just ran into a
> > situation where shared signal blocking would have been very useful on Linux).
> > You basically want to protect your data structures that could be accessed
> > by signals against signals send to any thread, otherwise sigprocmask
> > are pretty useless.
>
> I _really_ really want to avoid this. I think POSIX is vague on the
> requirement, and quite frankly, a shared sigprocmask() is a horror. It
> really doesn't fit in, at all.
I think shared sigprocmask is very useful. How otherwise would you lock
against signals in a multithreaded process ? Locking is really
needed when you're e.g. using queued SIGIO for IO. Doing the locking
in user space is really nasty in this case
[I just stumbled over a case this week were it would be really useful]
> In contrast, a shared sigprocmask() simply isn't going to happen. That is
> a 2.5.x issue, and even in 2.5.x I'd really like to avoid it, because it
> would be a design mistake, I suspect.
Just how would you protect your queued SIGIO datastructures otherwise ?
But I agree that it is probably 2.5 material.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:13 EST