[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

I think the whole DoesWaitPidYield thing is a red herring.  Can you  
just wait for me to put in my fix to the CVS head and you can look and  
see what you think?  I would really like to reinstate the original  
structure for m3core/src/thread too, but I don't know what the  
constraints are w.r.to your C header file hacking and the need for  
Cygwin to have a SchedulerPosix implementation.

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On 12 Jan 2009, at 18:01, Jay wrote:

> I need to go back and study that. It implies I missed something big  
> when I made the change.
> I could have sworn I looked at the functions and decided one could  
> not be implemented
> on top of the other but it sounds like I missed one. Hold on.
>
> DoesWaitPidYield is not the problem really though.
> We agree, at its worst, it would be cloned, in regular Modula-3 code  
> (not quake).
> At its best, it would be gone.
>
> The bigger change is sharing the SchedulerPosix implementation on  
> Win32 threads for Cygwin.
>
>  - Jay
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Mon, 12 Jan 2009 17:49:55 +1100
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] CVS Update: cm3
>
> Why do you need DoesWaitPidYield?  As I mentioned in another post,  
> fixing sysutils to use a properly scheduled version of waitpid is  
> trivial. I don't think you need all this DoesWaitPidYield junk.
>
> Frankly, I think the threads code is now a mess and needs to be  
> reverted.
>
> 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/m3devel/attachments/20090112/ca153369/attachment-0002.html>