All of lore.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Dave McCracken <dmc@austin.ibm.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status
Date: Mon, 20 Aug 2001 12:52:05 -0700	[thread overview]
Message-ID: <3B816A65.5BA70FFF@mvista.com> (raw)
In-Reply-To: <E15Yrlh-0006JF-00@the-village.bc.nu> <26210000.998324773@baldur> <3B815BFD.80D62209@mvista.com> <23580000.998333953@baldur>

Dave McCracken wrote:
> 
> --On Monday, August 20, 2001 11:50:37 -0700 george anzinger
> <george@mvista.com> wrote:
> 
> > Are you possibly also looking into allocating a small data structure to
> > the thread group?  A place to keep thread group signal info, perhaps?
> 
> No, not specifically.  A mechanism already exists to share info between
> cooperating tasks, where there's a common structure pointed to by each task
> (ie mm_struct, signal_struct, files_struct, fs_struct, etc).  I think we
> can use this mechanism for any info a group of tasks needs to share.
> 
But this (signal_struct) does not share the signals, just the
infrastructure.  I believe the thread standard defines some signals that
are to be delivered to a "thread leader" regardless of what actually
caused the signal.  Thus for these signals a separate mask & signal
queue seems in order.  I suppose one could use the union of all the
thread masks or some such, but this seems like a lot of overhead.  Also
need to introduce the concept of a "thread leader" (the thread that this
group of signals is to be delivered to) and what happens when the
"thread leader" exits (how a new "thread leader" is chosen).  I suspect
that the standard addresses all this, but I don't yet have access to the
standard.

Then, again, I could be suffering from too much coffee :)

George

  reply	other threads:[~2001-08-20 19:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-20 15:39 [PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status Dave McCracken
2001-08-20 16:19 ` Alan Cox
2001-08-20 16:26   ` Dave McCracken
2001-08-20 18:50     ` [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status george anzinger
2001-08-20 18:59       ` Dave McCracken
2001-08-20 19:52         ` george anzinger [this message]
2001-08-20 20:03           ` Dave McCracken
2001-08-20 19:09     ` [PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status Miquel van Smoorenburg
2001-08-20 19:15       ` Ulrich Drepper
2001-08-20 19:30       ` Dave McCracken

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B816A65.5BA70FFF@mvista.com \
    --to=george@mvista.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dmc@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.