lkml.org 
[lkml]   [1999]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: kernel thread support - LWP's
Date
> >I remember someone (David Wragg <dpw@doc.ic.ac.uk>) once mentioned another
> >new flag idea: a CLONE_SIBLING flag, which will mean that if the new
> >thread does a clone() the new thread will get the same ppid of the parent.
> >This (together with the redefinition of the manager thread, above) will
> >mean that all of the threads report directly to the manager, and any
> >thread may create another thread _without_ communicating to the manager
> >(it just creates a new sibling).
>
> I like it.

I like it too. I'm doing it right now. Only problem is notifying the
parent that it had a child without knowing it! (Next on Jerry Springer..)

Semantics are basically this:

Any process created with the CLONE_PPIDOK flag is allowed to make children
for its parent. It can then be clone()d with CLONE_PPID, and do_fork()
will do the right thing wrt p_pptr and p_opptr.

outstanding issues:

1) send a signal to parent? SIG_NEWCHLD ? ick... but not notifying parent
is silly..

2) what if we ask for CLONE_PPID and CLONE_PPIDOK (which is copied into
task_struct flags as PF_PPIDOK) is not set? We can eitehr fail with EINVAL
(or better error?) or silently ignore CLONE_PPID. I opt for ignoring it
and clone()ing as usual.

any other thoughts?


Tim


-
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:53    [W:0.064 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site