Yes, that's right.
Sape
> From: x...@bouyapop.org
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Jun 3 09:15:42 CES 2010
> Subject: Re: [9fans] run queues
>
>
> Thank you. That's what I was thinking. I suppose this ha
Thank you. That's what I was thinking. I suppose this has been written
like this because traversing the queue might require too much time for
having a lock.
Phil;
Sape Mullender wrote:
Well spotted. But the queue is maintained in a way that
traversing it while it's being changed cannot cause
Well spotted. But the queue is maintained in a way that
traversing it while it's being changed cannot cause one
to address garbage (rnext always contains a pointer to a
proc or nil) and, at the label found, the sanity check
is performed to see if we really have a proc on the queue
in our hands.
Hi 9fans,
While reading src/9/port/proc.c:^runproc, I realized that the
following code is called without any lock. I would expect one in order
to walk through the each rq lists, as it is called with interrupt
enabled.
I think this would not crash the system because procs are not
dynamically all
