[M3commit] [M3devel] CVS Update: cm3

[Tony Hosking]

Well, I find the repacking somewhat dubious, but without knowing what  
the clients of Process.Wait and System.Wait expect, perhaps we should  
leave it that way for now.  Certainly, client code that has endian- 
ness  assumptions built in regarding the status value is clearly  
broken and should be fixed at source, rather than relying on some  
weird underlying repacking hack.  I will retain the current packings.   
As I understand it, the current contortions are to provide an  
implementation of SchedulerPosix for Win32 threads platforms like  
Cygwin that are otherwise POSIX.  Correct?

On 12 Jan 2009, at 19:30, Jay wrote:

> Asking me? I don't know.
> What sysutils does, sort of does. Right?
> You know -- there is the exit code or the exit signal.
> It seems to be using roughly (exit signal << 8) | exit code.
>
> I tried to "just" read the code (~ two weeks) but I might have read  
> it wrong and I don't remember what I found, only that I meant to  
> retain semantics, except for the efficiency of the wait.
>
> I don't think that explains the repacking though.
> I have to read it again (again, again).
>
> That's what m3core was hiding, the exit signal?
> I'll check.
>
>  - Jay
>
>
> From: hosking at cs.purdue.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 12 Jan 2009 19:13:38 +1100
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3commit] [M3devel] CVS Update: cm3
>
> What clients of waitpid actually care about the status bits?
>
>
> On 12 Jan 2009, at 18:07, Tony Hosking wrote:
>
> PS What is the name ThreadPScheduler supposed to connote?
>
> On 12 Jan 2009, at 17:44, Jay wrote:
>
> I basically agree here.
> I view thread.quake as temporary.
> Once m3core (that you bootstrap from) has  
> SchedulerPosix.DoesWaitPidYield, sysutils can use it itself.
>   Or some other fix involving sysutils not knowing this (it sounds  
> like you an easy one that I missed).
>
> And then the code that is generated when building m3core can be the  
> exact checked in code, was my intention.
>
> I guess what I could/should have done is just put in  
> SchedulerPosix.DoesWaitYield, wait some amount of time, and then  
> move sysutils over it, not fix sysutils asap.
>
> I can go ahead and do that now -- "fix" m3core, re-"break" (slow  
> down) sysutils, and then at whatever time, have sysutils use the new  
> function.
>
> I had noticed cygwin builds seeming to take way way longer than I  
> remember, like >12 hours instead of <1hour. I didn't track down if  
> this is the cause.
>
>  - Jay
>
> > From: hosking at cs.purdue.edu
> > To: jkrell at elego.de
> > Date: Mon, 12 Jan 2009 11:18:29 +1100
> > CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> >
> > I really hate the idea that thread.quake exists.
> >
> > Screw sysutils working against old m3core versions. sysutils doing
> > thread-related scheduling is a big hack, and should be killed now
> > before it infects others. I don't want to see thread-dependent code
> > outside of m3core. We really need to come to consensus on this  
> before
> > you do more damage to the core thread libraries.
> >
> > I feel strongly about this!
> >
> > -- Tony
> >
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090112/9a0da619/attachment-0002.html>