[M3devel] p007 not terminating on NT386

[Jay K]

> take a closer look
 
Sure.
 
I'm suspicious of the entire approach actually.
I understand that layering/pipelining Rd/Wr can be very nice,
but I think there are better approaches here.
 
1) Don't layer a Wr over a Wr.
Just have a worker thread and a table of weakrefs to Wr.
 
Understandable downside to this approach is without
an interception point, it doesn't know if a Wr has any data
worth flushing, it would needlessly flush idle Wrs.
 
or
 
2) Mark the upper Wr as not buffered -- not clear to me if adding buffering to unbuffered Wr is a goal. I'm not sure unbuffered Wr even makes sense, I have to reread it..
 
 
Underlying point is that, let's say I have a "counting Wr"..you know a Wr of very little but non-zero semantic. It seems too difficult imho to layer in a Wr that does very little. But again, I should reeread.
 
Thank you for fixing the test case.
I'll have to try Cygwin again here.
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Tue, 1 Sep 2009 10:54:26 -0400
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] p007 not terminating on NT386
>
> On 1 Sep 2009, at 10:13, Jay K wrote:
>
>>
>> AutoFlushWr:
>> on non-I386_OPENBSD, it passed in the test runs, but generally hit
>> assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe
>> others.
>> on I386_OPENBSD: it hangs
>>
>>
>> The code was a bit hard for me to verify the correctness of. I
>> replaced it with an easy to understand version and the non-
>> I386_OPENBSD problems went away. The I386_OPENBSD hang remains.
>>
>>
>> In particular, AutoFlushWr layers a Wr over a Wr, but if the
>> underlying Wr is buffered, it strives to not add an additional
>> buffering layer. If the underlying Wr is not buffered, it does add
>> buffering. All Wrs have a few public fields to implement buffering.
>> AutoFlushWr copies these fields back and forth. I think it was a)
>> optimizing which fields to copy based on knowing which fields the
>> toplevel Wr modified when b) I think it was doing some computation
>> them that it should not have, instead of just copying them. I just
>> have it basically copy all the fields all the time. There are just a
>> few.
>
> OK, sounds like we all need to take a closer look at this code and
> satisfy ourselves that it is now correct.
>
>> Agreed, the I386_OPENBSD hang might be related.
>> I think I might have to try out very old versions, like I'm doing
>> (slowly!) for the formsedit crash.
>> Maybe not, since the I386_OPENBSD hang is easy to reproduce and only
>> involves two threads -- not too complicated.
>
> This is particularly weird, since it is clear that the main thread is
> trying to stop the other thread, but the other thread is not
> responding. I wonder if signal delivery to waiting threads is broken
> on OpenBSD?
>
>> I think p007 also hangs on Cygwin, but it always has. I tried
>> debugging it but Cygwin seemed like a mess. Granted, it hung with
>> Cygwin whether or not I used pthreads or NT threads.
>
> I have a feeling p007 is just buggy in itself -- it looks like there
> is a serious race in there. So, in this case I think the test is
> broken, not the platform. I'll try to clean it up.
>
>
>> Recentness isn't particularly clear I think, since I don't think
>> these platforms have ever had good test coverage. But I did think
>> regular NT386 was ok here.
>>
>>
>> Later,
>> - Jay
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> To: wagner at elegosoft.com
>>> Date: Tue, 1 Sep 2009 09:51:23 -0400
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] p007 not terminating on NT386
>>>
>>> These thread problems are relatively new (similar to Jay's problems
>>> with AutoFlushWr...). Something quite bad must have happened
>>> recently to cause them. I took a quick look at ThreadPThread.m3 but
>>> didn't notice anything obviously wrong. Something else perhaps?
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>
>>>
>>>
>>> On 1 Sep 2009, at 08:56, Olaf Wagner wrote:
>>>
>>> It looks as if m3test p007 does not terminate any more on NT386.
>>> This used to work. I just found this
>>>
>>> --- p007 --- a whole bunch of threads - does the memory grow ?
>>>
>>> cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw
>>> 2>NT386\stderr.build.raw
>>>
>>> running for more than 5 hours.
>>>
>>> The last successful run was
>>> http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/
>>> .
>>>
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23
>>> 45 86 95
>>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:
>>> Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>> DE163214194
>>>
>>>
>