[M3devel] ThreadPThread (PTHREAD)

[Jay]

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