[M3devel] [M3commit] CVS Update: cm3
Tony Hosking
hosking at cs.purdue.edu
Mon Jan 12 02:46:54 CET 2009
You are smearing implementation details across multiple files and
directories. Up until now, ThreadPThread has been nicely self-
contained, and captured all the basic pieces of the thread
implementation. Also, how does all of this fit with the ThreadPosix
implementation?
On 12 Jan 2009, at 12:19, Jay wrote:
> btw, I don't think it's that hairy, I merely split it into two or
> three files, and added interfaces so they can reuse code with each
> other. Movement between files is hard to track though (depending on
> version control, but with all I've used).
>
> The SchedulerPosix implementation moved to ThreadPScheduler.m3.
> What is shared between it and ThreadPThread/Win32.m3 is
> ThreadInternal.i3, which maybe should be in ThreadF.i3, though
> that's exposed outside m3core, and ThreadInternal.i3 includes a
> variable.
>
> I can try again to debug Cygwin pthreads though.
>
> - Jay
>
>
> > From: hosking at cs.purdue.edu
> > To: jkrell at elego.de
> > Date: Mon, 12 Jan 2009 11:03:33 +1100
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> >
> > Jay,
> >
> > Can you remind me again why Cygwin was unable to use pthreads? It
> > seems you have introduced a bunch of hair into the PTHREADS
> > implementation to deal with broken Cygwin pthreads. As many of us
> > have already pointed out, Cygwin should be a port that tries as much
> > as possible to be like a standard POSIX platform (pthread-based) as
> > opposed to a weird Windows/POSIX hybrid.
> >
> > I have a bunch of code that will be going into the PTHREADS base
> that
> > I am now at a loss to integrate with the changes you have made.
> >
> > Help!
> >
> > -- Tony
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090112/357a7f37/attachment-0002.html>
More information about the M3devel
mailing list