[9fans] what am i missing

[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");
}

Re: [9fans] what am i missing

[Russ Cox]

On Wed, Apr 25, 2012 at 3:46 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> 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

Re: [9fans] what am i missing

[erik quanstrom]

On Wed Apr 25 16:04:06 EDT 2012, rsc@swtch.com wrote:
> On Wed, Apr 25, 2012 at 3:46 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> > 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

Re: [9fans] what am i missing

[Russ Cox]

On Wed, Apr 25, 2012 at 4:06 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> 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

Re: [9fans] what am i missing

[erik quanstrom]

On Wed Apr 25 16:15:27 EDT 2012, rsc@swtch.com wrote:
> 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

Re: [9fans] what am i missing

[Russ Cox]

On Wed, Apr 25, 2012 at 4:37 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Wed Apr 25 16:15:27 EDT 2012, rsc@swtch.com wrote:
>> 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

Re: [9fans] what am i missing

[erik quanstrom]

On Wed Apr 25 17:01:18 EDT 2012, rsc@swtch.com wrote:
> On Wed, Apr 25, 2012 at 4:37 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> > On Wed Apr 25 16:15:27 EDT 2012, rsc@swtch.com wrote:
> >> 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