[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

Jay,

Your changes are occurring way too fast for us to keep up with you,  
and some of them are distorting the code base unnecessarily.   When  
you make these sorts of drastic reorgs it is important that the  
primary developers are in consensus.   Right now I am most distressed  
by the damage that seems to have been done to m3core/src/thread -- I  
haven't had time to look over the other things you've been doing  
closely enough to know.

For now, I am going to go in and change the source code head to  
reflect what I believe the solution for waitpid should look like.

On 12 Jan 2009, at 17:53, Tony Hosking wrote:

> Why does sysutils need to be compatible with both old and new  
> versions of m3core?
>
> On 12 Jan 2009, at 17:39, Jay wrote:
>
>> ThreadPosix is basically unaffected -- I never provided user  
>> threads on Cygwin.
>>  I guess it got a slight reduction regarding DoesWaitPidYield, but  
>> its SchedulerPosix implementation was unchanged.
>>
>> The code in ThreadPosix is similar to but different than  
>> ThreadPThread.
>> It is possible they could be merged but it wasn't trivial so I left  
>> ThreadPosix alone.
>>
>>  > You are smearing implementation details across multiple files  
>> and directories
>>
>> You really think it is bad to have SchedulerPosix implemented in a  
>> small separate file?
>> On top of what happens to be common implementation details of  
>> ThreadPThread.m3 and ThreadWin32.m3?
>>
>> ThreadPScheduler.m3 is just basically three functions: IOWait,  
>> IOAlertWait, XIOWait
>> Plus the little internal utility, UTimeFromTime, the one liner  
>> DoesWaitPidYield, and non-trivial functions nested in XIOWait:  
>> TestFDS, CallSelect.
>>
>> I mean, you know, an alternative is to copy out very large chunks  
>> of ThreadWin32.m3 and ThreadPThread.m3 and merge them into  
>> ThreadCygwin.m3. That would be worse imho.
>>
>> "Directories" hardly.
>>
>> Or I can try debugging cygwin pthreads again.
>>
>>  - Jay
>>
>>
>> CC: jkrell at elego.de; m3devel at elegosoft.com
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>> Date: Mon, 12 Jan 2009 12:46:54 +1100
>>
>> 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/b0cc4cbf/attachment-0002.html>