Subject: Re: curproc in procfs
To: None <tech-kern@netbsd.org>
From: Guenther Grau <Guenther.Grau@bk.bosch.de>
List: tech-kern
Date: 03/05/1999 09:17:27
Hi Gordon,
"Gordon W. Ross" wrote:
>
> On Thu, 4 Mar 1999 11:25:09 -0800 (PST)
> Bill Studenmund <wrstuden@nas.nasa.gov> wrote:
> > Maybe it would make sense to add curprocX, leaving curproc as-is. curproc
> > referes to the process making the open() call, while curprocX refers to
> > the curproc on cpu X.
> >
> > Thoughts?
>
> Jason Thorpe replies:
> > I don't really think this is a great idea.
>
> I agree. Here's why:
>
> The assignment of CPUs to any particular thread or process is
> going to be very dynamic (at least eventually:) so any such
> information you might expose at user-level is guaranteed to be
> out-of-date by the time it even gets to user-level. Better no
> information than misinformation.
I generally agree, but isn't the current curproc also subject
to change any time? I wouldn't actually know what one'd use it
for ... If it really points to the process currently exectuting,
then the process currently executing will be able to access
itself through it, not? Hmm, well, in a multiprocessor world
a process/thread running on one CPU might be able to identify
the processes/threads running on the other CPU. But what would
the process do with this information? It's only a snapshot and
could change any time/second/...
Well, maybe it's just too early this morning :-)
Guenther