From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 25 Apr 2012 17:10:15 -0400 To: 9fans@9fans.net Message-ID: <43753423e1d13c42e5a6d0feb69f52d9@brasstown.quanstro.net> In-Reply-To: References: <16d20c29be00a62eacb3dba96a700922@brasstown.quanstro.net> <44a20375d50e77dfb05d75c5ab989474@brasstown.quanstro.net> <12d49fddae516ea31fe10407d7547b06@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] what am i missing Topicbox-Message-UUID: 7f99d900-ead7-11e9-9d60-3106f5b1d025 On Wed Apr 25 17:01:18 EDT 2012, rsc@swtch.com wrote: > On Wed, Apr 25, 2012 at 4:37 PM, erik quanstrom = wrote: > > On Wed Apr 25 16:15:27 EDT 2012, rsc@swtch.com wrote: > >> This is not Linux. =C2=A0Each 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? >=20 > 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 !=3D 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. =20 - erik