[9fans] what am i missing

[erik quanstrom]

i just modified _schedexecwait to not eat wait messages.

i think that if you're asynchronously procexecing() and
waiting for wait messages, some could have been lost.

have i missed something? this seems too basic.

- erik
---

void
_schedexecwait(void)
{
int pid;
Channel *c;
Proc *p;
Thread *t;
Waitmsg *w;

p = _threadgetproc();
t = p->thread;
pid = t->ret;
_threaddebug(DBGEXEC, "_schedexecwait %d", t->ret);

rfork(RFCFDG);
for(;;){
w = wait();
if(w == nil)
break;
if(w->pid == pid)
break;
++ if((c = _threadwaitchan) != nil)
++ sendp(c, w);
++ else
free(w);
}
if(w != nil){
if((c = _threadwaitchan) != nil)
sendp(c, w);
else
free(w);
}
threadexits("procexec");
}

[Russ Cox]

Post by erik quanstrom
i think that if you're asynchronously procexecing() and
waiting for wait messages, some could have been lost.

why would they be delivered to the proc running procexec?

russ

[erik quanstrom]

Post by Russ Cox

Post by erik quanstrom
i think that if you're asynchronously procexecing() and
waiting for wait messages, some could have been lost.

why would they be delivered to the proc running procexec?

good point. procrfork() does nowait. but then how do i get
a wait message. i'm really hoping the answer is not "you don't".

- erik

[Russ Cox]

good point.  procrfork() does nowait.  but then how do i get
a wait message.  i'm really hoping the answer is not "you don't".

I don't believe you have looked at the context here.

This is only used by procexec, which is trying to simulate
an exec replacing a proc. It does that by setting p->needexec=1
and jumping back into the scheduler. The scheduler will call
_schedexec, which does an rfork of its own (not procrfork),
the "exec"ed program runs in the child, and the parent waits
for the wait message saying the child is done. An unexpected
wait message shold not come in, but if one does, might as well
be tidy and free it before continuing the loop.

This is not Linux. Each individual proc (thread) has its own
set of children, so the only wait message that should arrive
on that proc is the one it expects. Other procexecs running
in other procs will not affect it.

Russ

[erik quanstrom]

Post by Russ Cox
This is not Linux. Each individual proc (thread) has its own
set of children, so the only wait message that should arrive

and yet the threadwaitchan() is shared among all threads in all
procs, no?

- erik

[Russ Cox]

Post by erik quanstrom

This is not Linux.  Each individual proc (thread) has its own
set of children, so the only wait message that should arrive

and yet the threadwaitchan() is shared among all threads in all
procs, no?

Yes, of course, but I don't understand why that is relevant.
We were talking about whether _schedexecwait should ever
get a Waitmsg with w->pid != pid that is not okay to throw
on the floor. Did you actually observe a problem using the
thread library? If so, an actual test program would be great.

Russ

[erik quanstrom]

Post by Russ Cox

Post by erik quanstrom

This is not Linux.  Each individual proc (thread) has its own
set of children, so the only wait message that should arrive

and yet the threadwaitchan() is shared among all threads in all
procs, no?

Yes, of course, but I don't understand why that is relevant.
We were talking about whether _schedexecwait should ever
get a Waitmsg with w->pid != pid that is not okay to throw
on the floor. Did you actually observe a problem using the
thread library? If so, an actual test program would be great.

no, i was confused. there is no bug.

the reason i'm noting that everything gets tossed on the same
channel with disappointment is that the idea was to create pairs
of processes sources (procrfork/procexecl) and proc sinks
(wait; but that doesn't work) so the total number outstanding/rate/
processor use could be managed independently for each.

- erik