<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Yes I can explain mostly.<BR><BR>
<BR>
I was not able to get Cygwin/pthreads to work.<BR>
I don't know why. I could try another round of debugging.<BR>
It was a while ago, like a year ago.<BR>
I did debug it on some depth, rebuilding cygwin1.dll, and such.<BR>
I was inclined to give up.<BR>
<BR>
Consensus at the time was people didn't really care.<BR>
As long as they had forward slashes (which are abstracted<BR>
from code, but not from the user..and slow fork..),<BR>
and Modula-3 abstracted threads,<BR>
no matter how the Modula-3 threads were impelented.<BR><BR>
<BR>
So Cygwin uses Win32 threads.<BR>
<BR>
<BR>
More recently..well, it bothered me slightly that the "wait" code was<BR>
duplicated, but that's very little code. In looking at it though, I realized<BR>
that Cygwin didn't have a proper SchedulerPosix, which I think is<BR>
an abstraction of select().<BR>
<BR>
<BR>
What I did is move the SchedulerPosix code out of ThreadPThread.<BR>
This way it can be reused against ThreadPThread or ThreadWin32.<BR>
<BR>
It is a fairly mechanical change, with no real semantic change.<BR>
I realize that movement of code from one file to another is hard to track though<BR>
using simple text methods.<BR>
<BR>
<BR>
The stuff around "WaitPidYields" is what got me looking here and<BR>
has some value, but I think giving Cygwin a proper SchedulerPosix<BR>
is more valuable.<BR>
<BR>
<BR>
WaitPidYields is contorted because sysutils bootstraps against old m3core,<BR>
and I strongly suspect that sysutils exposes essentially a different<BR>
variant of m3core's abstractions, and cannot be implemented on top of it.<BR>
That m3core hides too much for sysutils.<BR>
<BR>
<BR>
If we bump up the minimum m3core that we build from, the contortions<BR>
can go away. "contortions" == "quake generating Modula-3 code,<BR>
with different names per client".<BR>
<BR>
<BR>
Make sense?<BR>
<BR>
- Jay<BR><BR><BR>> From: hosking@cs.purdue.edu<BR>> To: jkrell@elego.de<BR>> Date: Mon, 12 Jan 2009 11:12:36 +1100<BR>> CC: m3devel@elegosoft.com<BR>> Subject: [M3devel] ThreadPThread (PTHREAD)<BR>> <BR>> Jay, can you give me a sense of what the purpose of your recent <BR>> changes to the pthread-based threading code are intended to achieve? <BR>> I haven't been able to follow too closely all the changes you are <BR>> making, and I would like some sort of high-level rationale to help me <BR>> understand. Also, if sysutils has thread-dependent stuff in it then I <BR>> suggest sysutils should be rewritten to call the thread code rather <BR>> than re-implement. m3core is a library that is always linked, so <BR>> sysutils could easily depend on it. What's the problem?<BR>> <BR><BR></body>
</html>