[M3commit] [M3devel] CVS Update: cm3

[Jay]

I can wait but I really don't think this structure is so awful, rehosting one SchedulerPosix implementation on top of two different threading libraries. Maybe just let Cygwin die?
 
 
Was the restructuring to use "spawn" sometimes instead of fork/exec also so bad?
I actually find that hard to read, but it is theoretically a very large improvement.Cygwin really fails badly compared to "Posix" in fork perf, even if the semantic matches.
(and vfork, which is what Modula-3 uses, doesn't help. Cygwin's vfork == fork, both slow.)
 
It is contorted also, but you know, we can't use a line by line #ifdef, so we have to break stuff up into separate files, which often seems less clear (but sometimes is more clear, it depends on how much is different and how much the same; the more that is the same, the better to have #ifdef, the more that is different, the better to have separate files).
 
 
Or, can I replit out SchedulerPosix after you apply your "actual" changes -- you know, just a way to avoid the merge, but keep the contituent diffs?
 
 
 - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:05:48 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3I 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 implementedon 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.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why 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/m3commit/attachments/20090112/9e57c669/attachment-0002.html>