From: george anzinger <george@mvista.com>
To: Dave McCracken <dmccr@us.ibm.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [RFC] POSIX personality
Date: Tue, 21 May 2002 14:13:01 -0700 [thread overview]
Message-ID: <3CEAB85D.1532F5A2@mvista.com> (raw)
In-Reply-To: <64270000.1022012868@baldur.austin.ibm.com>
Dave McCracken wrote:
>
> As part of improving support for POSIX multithreading I've been putting
> together some patches to allow more things to be shared between tasks.
> Right now this is accomplished via flags to clone() with one flag per
> resource to be shared. This usually translates to a data structure pointed
> to out of task_struct, complete with reference count and lock.
>
> In a discussion today an alternate idea was proposed by Ben LaHaise. He
> suggested creating a POSIX personality, or execution domain. This would
> take some pressure off the clone flag space as well as allowing some
> optimizations in the code. It could also be used in situations where
> POSIX-compatible behavior entails more than just sharing extra resources
> between tasks.
>
> This would assume that the resources I'm sharing would only be useful for
> POSIX compatibility, but at this point it seems unlikely that anyone would
> want to share a subset of them. The resources I'm currently working on
> include credentials, signals, and timers, and there's a patch available
> for semaphore undo that could also be part of this mechanism.
>
> Since you've made it this far my question to you all is this: assuming
> that we do want improved POSIX compatibility does this sound like a
> reasonable way to add it?
>
What you are proposing seem a bit vague. I think that
CLONE_THREAD should group all the thread related stuff under
the one flag. IMHO POSIX compatibility should not be off in
the corner as a step child, but rather should be the norm.
The CLONE_THREAD flag would indicate to fork that it should
create a POSIX thread and set up the needed shared stuff. I
rather image this to be a structure that each task_struct
points to, possibly with a usage count (but that is a
detail). Each thread_struct would point to such a
structure, but processes that are not threaded would not be
sharing this area with other threads.
Is this close to what you had in mind?
-g
>
> ======================================================================
> Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
> dmccr@us.ibm.com T/L 678-3059
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2002-05-21 21:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-21 20:27 [RFC] POSIX personality Dave McCracken
2002-05-21 20:52 ` Linus Torvalds
2002-05-21 20:56 ` Dave McCracken
2002-05-23 14:10 ` Bill Davidsen
2002-05-23 17:09 ` Linus Torvalds
2002-05-25 0:02 ` jw schultz
2002-05-25 0:38 ` Alan Cox
2002-06-05 13:26 ` Bill Davidsen
2002-05-21 21:13 ` george anzinger [this message]
2002-05-21 21:21 ` Dave McCracken
[not found] <Pine.LNX.4.33.0205211349100.3073-100000@penguin.transmeta.com.suse.lists.linux.kernel>
[not found] ` <72190000.1022014608@baldur.austin.ibm.com.suse.lists.linux.kernel>
2002-05-21 21:35 ` Andi Kleen
2002-05-21 23:08 ` Linus Torvalds
2002-05-22 14:19 ` Dave McCracken
2002-05-28 17:26 ` Michael Sinz
2002-05-28 17:31 ` Dave McCracken
[not found] <187597808@toto.iv>
2002-05-21 23:55 ` Peter Chubb
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=3CEAB85D.1532F5A2@mvista.com \
--to=george@mvista.com \
--cc=dmccr@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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.