[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