lkml.org 
[lkml]   [1999]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: clone, signal and pids
Luis Irun <lirun@iti.upv.es> writes:
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: David Wragg <dpw@sytry.doc.ic.ac.uk>
Date: 11 Feb 1999 01:13:14 +0000
Message-ID: <y7r4sotspxx.fsf@sytry.doc.ic.ac.uk>
Lines: 21
X-Mailer: Gnus v5.5/XEmacs 20.3 - "Vatican City"

> The matter is: I don't agree the
> signal behaviour for clones sharing its pid's.

The impression I've got from the code is that CLONE_PID isn't supposed
to have any particular semantics, as long as it doesn't expose
security holes (which it diesn't seem to). I assume sensible semantics
were supposed to be implemented at a later date, but no-one has got
round to it. The obvious user-space semantics are those for POSIX
thread signals, but it isn't quite so obvious which kernel additions
would be most useful for a low-overhead user-space implementation.

> [snip]
> I think the wrong step is allowing the clones to share its pid's.

I suspect no-one has actually made real-world use of CLONE_PID from
user-space. It is however used inside the kernel (creating the idle
task for each processor on SMP, which should all have the same pid of
0).

Dave Wragg


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.048 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site