[M3devel] RC merge

[Jay K]

Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be.

I propose a few options:
 1 - asis, probably not
 2 - rename/merge ThreadUnsafe to ThreadInternal
 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too

2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal

3 maybe gratuitously breaks folks but is a clean result

 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe.

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Fri, 11 Sep 2009 16:51:11 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] RC merge

Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff.
FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system.  Is there any need for it really to be safe?
On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes.

http://www.modula3.com/cm3/ChangeLog-2009

"
2009-09-08 05:54 hosking

  * m3-libs/m3core/src/: convert/CConvert.m3,
    runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3,
    runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3,
    runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3,
    runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3,
    runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3,
    runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3,
    thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3,
    thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3,
    thread/WIN32/ThreadWin32.m3:

  Tidy up use of thread.inCritical to only occur in allocation sequences and in
  thread stoppage.  This simplifies reasoning.  Refactored use of heap lock
  in the process.  This may be better implemented on PTHREAD targets using a
  recursive pthread mutex instead of one we roll ourselves from a non-recursive
  mutex.

  Still witnessing random hangs in Juno and mentor on I386_DARWIN.
  Strange, I thought this was working previously.
  I wonder if there is some sort of race in the GUI code somewhere?
"

??-  Jay


From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Fri, 11 Sep 2009 12:46:19 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] RC merge

No, the hangs in Juno and mentor are no longer there.  I cannot reproduce them on I386_DARWIN.

On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed?
 
How does one do it easily?
I wish we used Perforce. :(

 - Jay

 
From: hosking at cs.purdue.edu
To: m3devel at elegosoft.com
Date: Fri, 11 Sep 2009 09:45:23 -0400
Subject: [M3devel] RC merge

Can someone merge my recent deep fixes to pthreads threading over to the release branch?  I won't get a chance to do so until next Monday at the earliest.

Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090911/1dcf6f0c/attachment-0002.html>