This is a discussion on Re: [9fans] Quick question on stopping a process that waits for IO - Plan9 ; > >> Did I miss something obvious? > > > > And this would be a million dollar question here. I don't > > think you did (although Eric (sic) constantly warns us of > > dragons), but on the ...
> >> Did I miss something obvious?
> > And this would be a million dollar question here. I don't
> > think you did (although Eric (sic) constantly warns us of
> > dragons), but on the other hand I have very little
> > experience with the kernel itself.
> I hope somebody comments on the fencing that is or isn't needed here. Since
> we have parts of the kernel peeking witout locks at ->procctl, I worry about
> races, and wonder how, or if, the current design avoids them.
memory fencing only forces the instruction
stream to be read, write or r/w coherent with
the local processor. it is of no help at all for
concurrent access. supposing there is a problem,
memory fencing will not help. you would need
an ilock. i didn't spend enough time looking
at pc/trap.c to convince myself one way or the
other, but the main access (other than syscall
tracing) seemed to be a read of the variable
to transition to stopped state. this race is
likely benign. you'll just go around again and
catch it later.
notes are hard. and the problem they're intended
to solve is how to interrupt a single-threaded process.
if you're writing something new and you think you
might want to extend notes, i think you would be
much happier using the thread library and living
in user space.
> in local store -- that drove the design of the Coyotos kernel to being a
> strictly transactional system. AFAIR there it is always possible to tell a
it's easy to have a design where you let the dragons
play and you need to bring out some serious weaponry
to deal with your problems. (and it is possible to get
carried away looking for concurrency problems.)
a good design like plan 9 keeps the dragons locked up,