[M3devel] ThreadPThread (PTHREAD)

[Tony Hosking]

On 12 Jan 2009, at 12:04, Jay wrote:

> 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.

But now you are distorting the whole threads subsystem to work around  
a bug.  Sounds screwy to me.

> 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.

I care if the threads system becomes a tangled mess.

> So Cygwin uses Win32 threads.

Fine insofar as the implementation is hidden.  But then you go on and  
try to impose POSIX thread semantics (for waitpid and friends) [as far  
as I understand things] onto a Win32 threads implementation.  Weird.

> 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.

Does this even make sense?

> 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.

I don't know what this comment refers to.  Can you give a high-level  
overview?

> 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.

sysutils is a *hack* that needs to be fixed so as not to expose m3core  
abstractions.    It is only used in a very few places, and we would be  
much better situated if we figured out what functionality is needed by  
clients of sysutils rather than breaking m3core to let sysutils in on  
things.

> 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".

What do you propose?  What is the "minimum m3core"?  What do we need  
to add to it?

>
>
>
> 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/15ebf79c/attachment-0002.html>