Roland McGrath <[EMAIL PROTECTED]> writes:
> > That's correct, but in the model of just "return null if the parent is
> > gone", why is this a problem?
>
> This model makes it impossible to guarantee an assignment of the task to
> its original Hurdish ancestor. I think that guarantee is the mos
Roland McGrath <[EMAIL PROTECTED]> writes:
> In general, what's most useful to profile are real programs running real
> workloads to see what spots actually matter in practice. Profiling
> targetted benchmarks (like the fork tester) mostly just confirms the
> spots of slowness you already know a
> That's correct, but in the model of just "return null if the parent is
> gone", why is this a problem?
This model makes it impossible to guarantee an assignment of the task to
its original Hurdish ancestor. I think that guarantee is the most valuable
part of the feature, because it allows unre
Roland McGrath <[EMAIL PROTECTED]> writes:
> I agree with Neal that a FS_TRANS_* flag is more appropriate--that leaves
> goaway_flags as purely flags passed on to the fsys_goaway RPC, which is a
> clear and easy thing to understand.
Yes, agreed, this is better than as a goaway flag. It should
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > I have no objection to adding a flag for file_set_translator to avoid
> > sending the goaway. But calling the flag "disconnect" is wrong: a
> > disconnect happens whether you set that flag or not.
>
> I fail to see how this is true: if the transla
Roland McGrath <[EMAIL PROTECTED]> writes:
> > * Mach needs a facility to find out what task is the parent of
> > a given task.
>
> I'm not sure if there was a particular motivation for this other than the
> kind of thing in proc that I suggested.
Also a process accounting motivation here
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Yes, this would work out the way you described it. How about Mach keeping
> track of the task hierarchy? I am not sure how exactly this would need to
> be implemented. Mach could keep a pointer to the parent task in the task
> structure. Someone
On Tue, May 15, 2001 at 01:00:35AM -0400, Roland McGrath wrote:
> I agree with Neal that a FS_TRANS_* flag is more appropriate--that leaves
> goaway_flags as purely flags passed on to the fsys_goaway RPC, which is a
> clear and easy thing to understand. I think we should call the new flag
> FS_TR
> * Mach needs a facility to find out what task is the parent of
> a given task.
I'm not sure if there was a particular motivation for this other than the
kind of thing in proc that I suggested. I'm not sure there is a reason to
do the kernel interface I suggested (propagating a value that pr
