if that scan through the runq fails (it always will, since runq->ret
is never set). then the wait message will be lost by Waitfor unless the
first wait message returned from the kernel happens to be the one we're
looking for.
perhaps what i wrote wasn't clear.
it's not so bad dropping the kernel's wait message, but in order for "wait $pid"
to work as advertised, Xasync would need to add $apid to a list and Waitfor
would need to remove it. this way, if the waitfor list is nil, we just complain
there's nothing to wait for instead of hanging. if it's not nil, then if the
wait
completed, we return otherwise we find the right member of the list and note
that it completed.
the list scan that's there i'm pretty sure is for non-Xasync processes only.
p->ret
is referenced in Xreturn and Xstart and Waitfor only.
- erik
On Mon Dec 18 15:06:38 EST 2006, [EMAIL PROTECTED] wrote:
> > since 20 is much less than 128, this can't be the kernel. i think the
> > problem is in the discarded wait messages here: rc/plan9.c/^Waitfor
>
> Where do you see discarded wait messages?
>
> > int
> > Waitfor(int pid, int)
> > {
> > thread *p;
> > Waitmsg *w;
> > char errbuf[ERRMAX];
> >
> > while((w = wait()) != nil){
> > if(w->pid==pid){
> > setstatus(w->msg);
> > free(w);
> > return 0;
> > }
> > for(p = runq->ret;p;p = p->ret)
> > if(p->pid==w->pid){
> > p->pid=-1;
> > strcpy(p->status, w->msg);
> > }
>
