l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On PATH_MAX


From: Marcus Brinkmann
Subject: Re: On PATH_MAX
Date: Mon, 07 Nov 2005 16:37:33 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 7 Nov 2005 08:18:13 -0700,
"Christopher Nelson" <address@hidden> wrote:
> 
> > 
> > On Mon, 2005-11-07 at 12:41 +0100, Marcus Brinkmann wrote:
> > 
> > > This is not true.  If for example A and B have exactly the same
> memory
> > > layout, and a symmetric trust relationship that involves
> coordination
> > > of memory regions, B will always be able to map exactly the same
> > > memory as A has.
> > >
> > > This is not a far-stretched scenario.  Such relationships do exist.
> > 
> > Indeed. The common term for this relationship is "multithreading".
> > 
> > But I think that somehow you and Christopher are talking past each
> > other.
> > 
> 
> Yes, exactly.  I mean two threads that don't exist in the same address
> space.  In general, you could call them two processes.  So far as a
> multithreading app is concerned, there is no possible provision for
> confinement, of individual threads -- at least on most modern
> processors, so that would be outside my query.

The problem is that you don't say what's _inside_ your query.

I could now refine my example, and say that the two threads are _not_
in the same address space, but they agree on a large region of
potentially shared memory, and share everything except for a small
private core.  Then you might say that you meant everything except
multi-threading _and_ my refined example, and then I will refine my
example further and so on.

Eventually we will reach something that will adequately describe the
case you mean.  But it is not my responsibility to try to find the
boundary by making up one example after another.  It would be much
more efficient if you would state the boundary yourself up front.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]