From jay.krell at cornell.edu Tue Dec 1 09:18:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:18:08 +0000 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: Oh darn, some hiccup on my phone has caused a bunch of emails to resent. Sorry for the horrendous noise. :( - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 02:02:47 +0000 > Subject: Re: [M3devel] This is a pixmap? > > > Trying again due to truncation. > > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: This is a pixmap? > Date: Thu, 3 Sep 2009 15:44:17 +0000 > > > > Does this look like a pixmap to anyone? > This is the parameter to Win32 Join. > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > t is at @ebp + here. > The pointer then is 00200000 at the start of the second line of the second dump. > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 09:31:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:31:21 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091130160501.GA24572@topoi.pooq.com> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu>, <20091130160501.GA24572@topoi.pooq.com> Message-ID: There certainly is such a campain in general. It has a few "labels". Posix glibc BSD sockets Mono C stdio.h gcc As well as "Linux" and "NT". The challenge then is weaving your way around options such as: chosing a very small number of systems, e.g. just NT chosing a very small number of features, e.g. stdio.h layering on some interface that you believe you can implement on top of multiple other systems e.g. Thread.i3, ThreadWin32.m3, ThreadPThread.m3 with various qualities, costs (maintenance, performance), etc. e.g. Trestle e.g. garbage collection (esp. when combined with Thread.i3) There is no one easy answer here. It helps that "chosing a very small number of systems" is a popular choice, thereby narrowing the field, unless you are/were one of the less popular systems. :) - Jay > Date: Mon, 30 Nov 2009 11:05:01 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > CC: hendrik at topoi.pooq.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > On Mon, Nov 30, 2009 at 09:48:48AM -0500, Tony Hosking wrote: > > This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. > > There seems to be a campaign to make all OS's behave the same to the > lowest possible code level. The only way to do that is to restrict > ourselves to a subset of their facilities that all share. I suspect > this is too restrictive. For popular platforms, at least, we should be > open to implement Modula 3 library features in a way that takes > advantage of those platforms peculiar abilities -- provided that the > library-user facilities remain compatible of course. > > That said, Windows is a popular platform that I have no use for (Windows > won't even install on my most-used machine -- for some obscure reason > it will only run in maintenance mode; my daughter says the machine is > corsed). The only thing I need Windows for is writing programs that > are to uised by other people. For that purpose, I do care that any > Modula 3 applications I write can be cross-compiled (ideally) and > immediately run properly on Windows without modification. > > But I suspect that is too much to expect in the real world, even with > the uncanny competence with which Modula 3 system is put togeter. > > -- hendrik > > > > > On 30 Nov 2009, at 13:03, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 09/11/30 13:03:07 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > > > > > Log message: > > > keep two thread handles > > > what to call them is unclear > > > here we ahve: > > > joinHandle > > > suspendResumeHandle > > > > > > aka: > > > pthread > > > ntthread > > > > > > on all but Interix (and possibly Cygwin), they are equivalent, > > > either the result of pthread_create or pthread_self > > > > > > on Interix, once is pthread_create/self, the other is a kernel handle > > > for suspend/resume > > > > > > alternate names welcome > > > the intent seems hoky, but helps much > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 09:43:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:43:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <6CED57F2-7E8F-4D7C-8DD0-8AE436BEF31B@cs.purdue.edu> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu>, <20091130160501.GA24572@topoi.pooq.com>, <6CED57F2-7E8F-4D7C-8DD0-8AE436BEF31B@cs.purdue.edu> Message-ID: Interest in Interix would probably track similarly with interest in Cygwin. They each have pluses and minuses. Interix in particular has a "normal" fast fork and is therefore far less unpleasant to use, esp. building m3cc. (Tip for Interix users: "net stop beep". I find Interix beeps a lot and the volume can't be controlled or muted (using the normal methods), such as when tab doesn't have anything to complete, etc.) - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 13:21:39 -0500 To: hendrik at topoi.pooq.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I was really just asking what the Interix target was good for. Windows users will want Windows integration, right? Rather than the Interix hybrid... On 30 Nov 2009, at 11:05, hendrik at topoi.pooq.com wrote: On Mon, Nov 30, 2009 at 09:48:48AM -0500, Tony Hosking wrote: This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. There seems to be a campaign to make all OS's behave the same to the lowest possible code level. The only way to do that is to restrict ourselves to a subset of their facilities that all share. I suspect this is too restrictive. For popular platforms, at least, we should be open to implement Modula 3 library features in a way that takes advantage of those platforms peculiar abilities -- provided that the library-user facilities remain compatible of course. That said, Windows is a popular platform that I have no use for (Windows won't even install on my most-used machine -- for some obscure reason it will only run in maintenance mode; my daughter says the machine is corsed). The only thing I need Windows for is writing programs that are to uised by other people. For that purpose, I do care that any Modula 3 applications I write can be cross-compiled (ideally) and immediately run properly on Windows without modification. But I suspect that is too much to expect in the real world, even with the uncanny competence with which Modula 3 system is put togeter. -- hendrik On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 11:06:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 10:06:46 +0000 Subject: [M3devel] Interix In-Reply-To: <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> Message-ID: I should point out that, like NT386, NT386GNU, NT386MINGNU, Interix is also in reality a few variables that can be mixed/matched. You can use either gcc or Visual C++ compiler and linker, and either the gcc backend or the integrated backend. In Interix, gcc is gcc (3.x or possibly 4.2), and cc is a wrapper around Visual C++ cl/link. They both work. For most code, indistinguishably, though definitely a little bit different feature sets. Interix does /not/, at least on XP, provide the other variables like C runtime, threading library, GUI library. After XP they do support "mixed mode" -- access to Win32 -- so then those choices would come back maybe. To help cc work, you can point $C89_COMPILER and $C89_LINKER at Visual C++ compiler/linker. (Similarly, you know, Intel has a compiler you can use on as I understand, Windows, Linux, MacOSX, x86, amd64, ia64?. I'm not sure it gets as much use as either gcc or Visual C++, but it is out there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; jkrell at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 30 Nov 2009 18:15:49 +0000 Interix is Posix (mostly) on NT, with fast fork. Cygwin in comparison is very slow. However SIGINFO is not available. Nor is "direct suspend" using a pthread_t I believe. The older Interix version on XP does not allow access to any Win32 functions. Newer versions do. This does seem to be a pretty useful platfom. Gui should be available too, but I have to work around some problem. - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 09:48:48 -0500 To: jkrell at elego.de CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Dec 1 12:01:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Dec 2009 06:01:54 -0500 Subject: [M3devel] Interix In-Reply-To: References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> Message-ID: <4B14B071.1E75.00D7.1@scires.com> Just out of curiosity, is anyone in the M3 community using or planning to use Interix ? I only plan to use native Windows, not Interix and not Cygwin. If no one wants Interix, perhaps current Interix efforts should be put on hold until the release is completed? Regards, Randy >>> Jay K 12/1/2009 5:06 AM >>> I should point out that, like NT386, NT386GNU, NT386MINGNU, Interix is also in reality a few variables that can be mixed/matched. You can use either gcc or Visual C++ compiler and linker, and either the gcc backend or the integrated backend. In Interix, gcc is gcc (3.x or possibly 4.2), and cc is a wrapper around Visual C++ cl/link. They both work. For most code, indistinguishably, though definitely a little bit different feature sets. Interix does /not/, at least on XP, provide the other variables like C runtime, threading library, GUI library. After XP they do support "mixed mode" -- access to Win32 -- so then those choices would come back maybe. To help cc work, you can point $C89_COMPILER and $C89_LINKER at Visual C++ compiler/linker. (Similarly, you know, Intel has a compiler you can use on as I understand, Windows, Linux, MacOSX, x86, amd64, ia64?. I'm not sure it gets as much use as either gcc or Visual C++, but it is out there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; jkrell at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 30 Nov 2009 18:15:49 +0000 Interix is Posix (mostly) on NT, with fast fork. Cygwin in comparison is very slow. However SIGINFO is not available. Nor is "direct suspend" using a pthread_t I believe. The older Interix version on XP does not allow access to any Win32 functions. Newer versions do. This does seem to be a pretty useful platfom. Gui should be available too, but I have to work around some problem. - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 09:48:48 -0500 To: jkrell at elego.de CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT:/usr/cvs Changes by:jkrell at birch.09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 12:01:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 11:01:10 +0000 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: I don't know if this is my phone or the mail server. Let's try turning off phone.. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 02:02:47 +0000 > Subject: Re: [M3devel] This is a pixmap? > > > Trying again due to truncation. > > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: This is a pixmap? > Date: Thu, 3 Sep 2009 15:44:17 +0000 > > > > Does this look like a pixmap to anyone? > This is the parameter to Win32 Join. > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > t is at @ebp + here. > The pointer then is 00200000 at the start of the second line of the second dump. > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 1 13:44:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Dec 2009 13:44:15 +0100 Subject: [M3devel] Final release sprint? was: Re: Interix In-Reply-To: <4B14B071.1E75.00D7.1@scires.com> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> <4B14B071.1E75.00D7.1@scires.com> Message-ID: <20091201134415.nk1fd6m59w8ocscg@mail.elegosoft.com> Quoting Randy Coleburn : > Just out of curiosity, is anyone in the M3 community using or > planning to use Interix ? > > I only plan to use native Windows, not Interix and not Cygwin. > > If no one wants Interix, perhaps current Interix efforts should be > put on hold until the release is completed? I really don't want to patronize anyone regarding his or her work on CM3, but it seems to be extremely difficult to concentrate the efforts on bringing the release engineering for 5.8 to an end. I currently cannot spend much time at all, and there are still several open tickets. I also haven't seen much (not to say none) feedback on the RC4 archives which are (mostly, some target platforms are still missing) available for several weeks. But in the meantime continuous integration has broken down several times on the release branch, so there must have been significant changes again. Very likely this release has already taken much too long, so that nobody is really interested anymore. It would be a pity if we don't get anything out the door though, as it will without doubt be much better than what was available before. As I said before, I'm unlikely to do any serious investigation or fixing during the next weeks. I can just have a look at the CI and ticket status now and then. If anybody wants to take over release engineering here, that would be OK for me, too; but I think that's rather unlikely, as I only volunteered because there was noone else ;-) So to summarize, I wouldn't say that nobody wants Interix or that it isn't worth the efforts, but I'd really appreciate if we could concentrate our efforts to finish the release. 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 From rodney_bates at lcwb.coop Tue Dec 1 16:35:48 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 01 Dec 2009 09:35:48 -0600 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <4B1537D4.8000909@lcwb.coop> I don't think it is your phone, because I happen to have changed the email address I use in my subscriptions, and the duplicate messages are all coming to the old email address. Must be the list server. Jay K wrote: > I don't know if this is my phone or the mail server. > Let's try turning off phone.. > > - Jay > > From rcoleburn at scires.com Tue Dec 1 20:32:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Dec 2009 14:32:21 -0500 Subject: [M3devel] build problem diagnosis in caltech-parser test package Message-ID: <4B150A90020000D700067FB8@scires.com> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 2 05:12:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Dec 2009 23:12:09 -0500 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> OK, this is getting ridiculous. Can someone at Elego give the mail-list server a poke to make sure it is not them resending as middle-man? Jay, do you have any ideas what could be going on at your end? On 3 Sep 2009, at 11:44, Jay K wrote: > > Does this look like a pixmap to anyone? > > This is the parameter to Win32 Join. > > > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > > t is at @ebp + here. > > The pointer then is 00200000 at the start of the second line of the second dump. > > > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Wed Dec 2 06:12:20 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 01 Dec 2009 21:12:20 -0800 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <20091202051220.E3A5D1A205E@async.async.caltech.edu> Why is this message looping over and over? This and another from Jay of the same day.. I must have received hundreds of copies by now. The messages are dated September 3 and 4. Mika Jay K writes: >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Trying again due to truncation. > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: m3devel at elegosoft.com >Subject: This is a pixmap? >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 > > > >Does this look like a pixmap to anyone? >This is the parameter to Win32 Join. >=20 >PROCEDURE Join(t: T): REFANY =3D > VAR res: REFANY=3B > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= >")=3B END=3B > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B > res :=3D t.result=3B > t.result :=3D NIL=3B > t.joined :=3D TRUE=3B > t.cond :=3D NIL=3B > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B > END=3B > RETURN res=3B > END Join=3B > >Very very often the crash is of the form of reading a pointer from 16 bytes= > into t and dereferencing it=2C plus or minus 4. >t is at @ebp + here. >The pointer then is 00200000 at the start of the second line of the second = >dump. >=20 >If we can confirm this is pixmap=2C we can hunt more around in the gui code= From jay.krell at cornell.edu Wed Dec 2 06:49:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Dec 2009 05:49:08 +0000 Subject: [M3devel] frequently recurring emails In-Reply-To: <20091202051220.E3A5D1A205E@async.async.caltech.edu> References: , <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: I don't know what is happening here but I don't think it is from me. On my end: - none of the messages are signed "phone" so not phone - I turned my phone off for hours so not phone ? - Jay > To: jay.krell at cornell.edu > Date: Tue, 1 Dec 2009 21:12:20 -0800 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] This is a pixmap? > > > Why is this message looping over and over? This and another from > Jay of the same day.. I must have received hundreds of copies by now. > The messages are dated September 3 and 4. > > Mika > > Jay K writes: > >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Trying again due to truncation. > > > >=20 > > > > - Jay > >=20 > > > > > >From: jay.krell at cornell.edu > >To: m3devel at elegosoft.com > >Subject: This is a pixmap? > >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 > > > > > > > >Does this look like a pixmap to anyone? > >This is the parameter to Win32 Join. > >=20 > >PROCEDURE Join(t: T): REFANY =3D > > VAR res: REFANY=3B > > BEGIN > > LOCK threadMu DO > > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= > >")=3B END=3B > > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B > > res :=3D t.result=3B > > t.result :=3D NIL=3B > > t.joined :=3D TRUE=3B > > t.cond :=3D NIL=3B > > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B > > END=3B > > RETURN res=3B > > END Join=3B > > > >Very very often the crash is of the form of reading a pointer from 16 bytes= > > into t and dereferencing it=2C plus or minus 4. > >t is at @ebp + here. > >The pointer then is 00200000 at the start of the second line of the second = > >dump. > >=20 > >If we can confirm this is pixmap=2C we can hunt more around in the gui code= -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Wed Dec 2 09:23:44 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Dec 2009 09:23:44 +0100 Subject: [M3devel] frequently recurring emails In-Reply-To: References: , <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: <20091202092344.rw3vpecq74gocg4g@mail.elego.de> ...looking into it. -Mike Quoting Jay K : > > I don't know what is happening here but I don't think it is from me. > > On my end: > > - none of the messages are signed "phone" so not phone > > - I turned my phone off for hours so not phone > > ? > > > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Tue, 1 Dec 2009 21:12:20 -0800 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] This is a pixmap? >> >> >> Why is this message looping over and over? This and another from >> Jay of the same day.. I must have received hundreds of copies by now. >> The messages are dated September 3 and 4. >> >> Mika >> >> Jay K writes: >> >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ >> >Content-Type: text/plain; charset="iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Trying again due to truncation. >> > >> >=20 >> > >> > - Jay >> >=20 >> > >> > >> >From: jay.krell at cornell.edu >> >To: m3devel at elegosoft.com >> >Subject: This is a pixmap? >> >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 >> > >> > >> > >> >Does this look like a pixmap to anyone? >> >This is the parameter to Win32 Join. >> >=20 >> >PROCEDURE Join(t: T): REFANY =3D >> > VAR res: REFANY=3B >> > BEGIN >> > LOCK threadMu DO >> > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= >> >")=3B END=3B >> > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B >> > res :=3D t.result=3B >> > t.result :=3D NIL=3B >> > t.joined :=3D TRUE=3B >> > t.cond :=3D NIL=3B >> > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B >> > END=3B >> > RETURN res=3B >> > END Join=3B >> > >> >Very very often the crash is of the form of reading a pointer from >> 16 bytes= >> > into t and dereferencing it=2C plus or minus 4. >> >t is at @ebp + here. >> >The pointer then is 00200000 at the start of the second line of >> the second = >> >dump. >> >=20 >> >If we can confirm this is pixmap=2C we can hunt more around in the >> gui code= > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Dec 2 10:03:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 10:03:31 +0100 Subject: [M3devel] Mail problems, was: Re: This is a pixmap? In-Reply-To: <20091202051220.E3A5D1A205E@async.async.caltech.edu> References: <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: <20091202100331.ho1xpesj4s408kc4@mail.elegosoft.com> Quoting Mika Nystrom : > Why is this message looping over and over? This and another from > Jay of the same day.. I must have received hundreds of copies by now. > The messages are dated September 3 and 4. This is strange. I didn't get hundreds of copies so I didn't really notice the problem. Mike is already investigating. If there is anything wrong with our services, please remember to include admins at elego.de, or at least m3-support at elego.de, or directly manderson at elego.de in your To: address. That will speed up the process. 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 From peter.mckinna at gmail.com Wed Dec 2 12:17:44 2009 From: peter.mckinna at gmail.com (peter mckinna) Date: Wed, 2 Dec 2009 22:17:44 +1100 Subject: [M3devel] Coverage tools Message-ID: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> Hi, Does the coverage tool actually work? I tried compiling with the -Z option after fixing up the C code in m3-tools/coverage but no luck. Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 2 12:56:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 12:56:35 +0100 Subject: [M3devel] Coverage tools In-Reply-To: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> References: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> Message-ID: <20091202125635.dcg5bwuo9sgc0wco@mail.elegosoft.com> Quoting peter mckinna : > Hi, > > Does the coverage tool actually work? > > I tried compiling with the -Z option after fixing up the C code in > m3-tools/coverage but no luck. I cannot say. It is probably legacy code from SRC that has not been used for many years and may fail due to various reasons now. We should probably document that. Can you also open a ticket (low priority) for the issue in trac? 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 From michael.anderson at elego.de Wed Dec 2 15:51:08 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Dec 2009 15:51:08 +0100 Subject: [M3devel] This is a pixmap? In-Reply-To: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> References: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> Message-ID: <20091202155108.let6ez86s8osgkc4@mail.elego.de> Hi All, The problem is on our end, not Jay's. I've identified the cause and am cleaning up now. Sorry for the spam. -Mike Quoting Tony Hosking : > OK, this is getting ridiculous. Can someone at Elego give the > mail-list server a poke to make sure it is not them resending as > middle-man? Jay, do you have any ideas what could be going on at > your end? > > On 3 Sep 2009, at 11:44, Jay K wrote: > >> >> Does this look like a pixmap to anyone? >> >> This is the parameter to Win32 Join. >> >> >> >> PROCEDURE Join(t: T): REFANY = >> VAR res: REFANY; >> BEGIN >> LOCK threadMu DO >> IF t.joined THEN Die(ThisLine(), "attempt to join with thread >> twice"); END; >> WHILE NOT t.completed DO Wait(threadMu, t.cond) END; >> res := t.result; >> t.result := NIL; >> t.joined := TRUE; >> t.cond := NIL; >> IF perfOn THEN PerfChanged(t.id, State.dead) END; >> END; >> RETURN res; >> END Join; >> >> >> Very very often the crash is of the form of reading a pointer from >> 16 bytes into t and dereferencing it, plus or minus 4. >> >> t is at @ebp + here. >> >> The pointer then is 00200000 at the start of the second line of the >> second dump. >> >> >> >> If we can confirm this is pixmap, we can hunt more around in the gui code > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Wed Dec 2 18:01:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 2 Dec 2009 09:01:49 -0800 (PST) Subject: [M3devel] Looking to update cm3 manual page. Message-ID: <538131.35719.qm@web56806.mail.re3.yahoo.com> Hi all, It has been more than half a year since I last looked at the CM3 manual page. I am now looking at the it in preparation for the release of version 5.8, and noticing some deficiencies. I asking for help in identifying any further places it is lacking. I can integrate any feedback into a revised manual page, and submit an updated version back to the archives. Currently identified deficiencies: o The manual page should explicitly state which version of the compiler it documents. o The sub-section "Expected Directory Structure" needs a better discussion, especially an introduction. o The discussion of mode option "-ship" mentions environment variable CM3_INSTALL_ROOT, yet in cm3.cfg we set INSTALL_ROOT without the "CM3_" prefix. This should be resolved. ** What is the exact meaning of these two? Is one recognized by the compiler, and the other by the supporting quake code? o The ENVIRONMENT section does not mention CM3_INSTALL_ROOT at all. Add a discussion about both INSTALL_ROOT, and CM3_INSTALL_ROOT. ** Am I missing any other environment variables? o Missing command line options for the compiler: - I currently have "-g", but no discussion of -gstabs. No discussion about not supporting DWARF (or do we?). o Compiler unique language features, (i.e., pragmas). The reference books (Nelson, and Harbison) give a list of suggested pragmas. The manual page should list the ones supported by the CM3 compiler explicitly, and show their syntax. ** Can someone list for me the pragmas supported by the current (5.8.4) compiler. o Should list any limitations of either the compiler, or the library suite provided with the compiler. For example, the WIDECHAR is limited by its 16-bit size to only a portion of the unicode character set (the basic multi lingual plane), whereas a unicode character is 20-bits, and we would need either a 24-bit or 32-bit sized type to contain it all. ** Are there any other known limitations of the compiler, or library suite? - length of identifier? - length of TEXT (ie, memory) - length of filenames, or pathname (some architectures may have differences, ie MS-Windows). o There should be a discussion of the @m3XXX runtime library command line options. o There should be an EXAMPLE section, with example source code (Hello world), along with supporting m3makefile. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Wed Dec 2 18:36:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 18:36:34 +0100 Subject: [M3devel] [Modula-3] Draft press release In-Reply-To: <864527.8311.qm@web56803.mail.re3.yahoo.com> References: <864527.8311.qm@web56803.mail.re3.yahoo.com> Message-ID: <20091202183634.nua52s60gssw4s08@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Olaf, > > I began working on writing a press release for the impending > official release. Would you either suggest any changes, or > simply take it and run with it. It's great that somebody starts to work on advertising! We should wait for the final release before publishing an official press notice though. As there have been many changes to threading again in the release branch, there should at least be an RC5 (which may then become the `official' release). Browsing your text, I don't see any mention of the threading improvements (system based threads default on almost all platforms --> better scaling on multi-processors, improved M3 user threads code) and garbage collection work. Perhaps we could insert some quotes from Antony? You may want to add more changes from the list at http://www.opencm3.net/releng/relnotes-5.8-RC4.html, though not every detail needs to be listed in the press release. cm3ide comes to mind, as well as m3gdb, improved Windows support, and REFANY extensions. > BTW: I went to the download page to download a copy of > the source for version 5.5, but only found binaries for > selected architectures. The sources are there, but `Sources' was missing in the heading. It's the first archive listed. > Also, that section was listed as > "Current Development Snapshots: CM3 d5.5.0". Do we really > want to say "Current"? No. I've removed several `current's :-) > *** BEGIN CUT *** > CM3 V5.8 PRESS RELEASE > > The CM3 software development team is pleased to announce > the release of CM3 version 5.8.4, is now available for > download from > > http://www.opencm3.net/download.html > > CM3 is an open source Modula-3 compiler, descended from the > Critical Mass Modula-3 compiler, which itself came from > Digital Equipment Corp (DEC) Systems Research Center (SRC)'s > m3 compiler. > > This is the first release of the 5.8 branch. It contains > many enhancements over the previous official release (5.5), > including (but not limited by): > > * Language enhancements: > o New primitive type > - LONGINT o Minimal tagged REFANY values > > * New supported architectures: > o AMD64_LINUX > o PPC_DARWIN This is not new, but I386_OPENBSD and AMD64_FREEBSD are. I'm not sure what will finally be available though. > o X86_DARWIN > o etc ... > > * Compiler Improvements > o Rebased on top of GCC-4.1 I think that should be 4.3. > o Additional information provided with version > information. > o Support configuration scripts (in quake) reworked > for more commonality between architectures. Runtime Improvements: o system-based threading default on most target platforms allowing better scaling on multi-processors o many enhancements to the garbage collector o optional alternative TEXT implementation which promises better performance o restructured low-level code avoiding redundancies, making new ports easier to create and maintain > * Additional software suites: o CM3-IDE, the open source release of Critical Mass' Reactor (tm) product > o Caltech-parser > o Cvsup. > > * Miscellaneous: > o documentation: > - Manual pages for (cm3, quake, m3makefile, ...). o much improved debugging with m3gdb > Some selected historical improvements of CM3 over the > original DEC-SRC m3 compiler are: > > * Language enhancements: > o New primitive type > - WIDECHAR, and new widechar literal > o New pragmas: > - ASSERT, > - DEBUG, > - IMPLICIT. > > * Text may contain Unicode characters, > * Support for dynamically linked (shared) libraries. > > * The quake supporting scripting language is now embedded > within the compiler itself. > > We hope everyone tries this latest version of our Modula-3 compiler, > and associated library suite. > > The CM3 Modula-3 development team. > *** END CUT *** > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ Probably I've missed something; others may check and extend the list. 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 From rcoleburn at scires.com Wed Dec 2 23:17:55 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Dec 2009 17:17:55 -0500 Subject: [M3devel] threads are broken on Windows Message-ID: <4B16A059.1E75.00D7.1@scires.com> Something is wrong with threads on Windows from the HEAD branch. After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 2 23:21:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Dec 2009 17:21:49 -0500 Subject: [M3devel] threads are broken on Windows In-Reply-To: <4B16A059.1E75.00D7.1@scires.com> References: <4B16A059.1E75.00D7.1@scires.com> Message-ID: <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> Jay's call on that one... On 2 Dec 2009, at 17:17, Randy Coleburn wrote: > Something is wrong with threads on Windows from the HEAD branch. > > After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 > *** > > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 > 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 > 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 > 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 > 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 > 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Dec 2 23:47:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Dec 2009 17:47:37 -0500 Subject: [M3devel] Looking to update cm3 manual page. In-Reply-To: <538131.35719.qm@web56806.mail.re3.yahoo.com> References: <538131.35719.qm@web56806.mail.re3.yahoo.com> Message-ID: <4B16A74F.1E75.00D7.1@scires.com> Peter: We need to make sure to add information about cm3IDE. The users guide can be found at: m3-sys\cm3ide\UsersGuide\CM3_IDE_UsersGuide.pdf Some of the environment variables you describe have to do with cm3IDE. Here is a list: CM3_IDE_HOME = env var for root of home folder HOME = alternate home folder root, if CM3_IDE_HOME not supplied The following variables are expected to be defined in the CM3.CFG file: INITIAL_CM3_IDE_BROWSER = full path to the web browser that should be used with cm3IDE INITIAL_CM3_IDE_EDITOR = full path to the text editor that should be called by cm3IDE BUILD_DIR = NT386, HPPA, etc. PKG_USE = full path to the public package root, e.g. /cm3/pkg DOC_INSTALL = full path to the documentation root, e.g. /cm3/doc If the first 2 are not defined, cm3IDE will prompt user on command line to provide these the first time it is run. Thereafter, it saves the information in its config file that it places in the CM3_IDE_HOME folder. If the last 3 are not defined, cm3IDE tries to construct them using heuristics. If not successful, the program will abort. cm3IDE requires that is "examples" folder be located off the installation root, e.g., cm3/examples. If examples is not found, cm3IDE will still run, but it will not be able to offer up any examples. In an environment that allows spaces in filenames, such as Windows, you can run into problems if any of the paths defined in these variables have embedded spaces. On Windows, you can get around this problem by using the short 8.3 name equivalent. Regards, Randy >>> Peter Eiserloh 12/2/2009 12:01 PM >>> Hi all, It has been more than half a year since I last looked at the CM3 manual page. I am now looking at the it in preparation for the release of version 5.8, and noticing some deficiencies. I asking for help in identifying any further places it is lacking. I can integrate any feedback into a revised manual page, and submit an updated version back to the archives. Currently identified deficiencies: o The manual page should explicitly state which version of the compiler it documents. o The sub-section "Expected Directory Structure" needs a better discussion, especially an introduction. o The discussion of mode option "-ship" mentions environment variable CM3_INSTALL_ROOT, yet in cm3.cfg we set INSTALL_ROOT without the "CM3_" prefix. This should be resolved. ** What is the exact meaning of these two? Is one recognized by the compiler, and the other by the supporting quake code? o The ENVIRONMENT section does not mention CM3_INSTALL_ROOT at all. Add a discussion about both INSTALL_ROOT, and CM3_INSTALL_ROOT. ** Am I missing any other environment variables? o Missing command line options for the compiler: - I currently have "-g", but no discussion of -gstabs. No discussion about not supporting DWARF (or do we?). o Compiler unique language features, (i.e., pragmas). The reference books (Nelson, and Harbison) give a list of suggested pragmas. The manual page should list the ones supported by the CM3 compiler explicitly, and show their syntax. ** Can someone list for me the pragmas supported by the current (5.8.4) compiler. o Should list any limitations of either the compiler, or the library suite provided with the compiler. For example, the WIDECHAR is limited by its 16-bit size to only a portion of the unicode character set (the basic multi lingual plane), whereas a unicode character is 20-bits, and we would need either a 24-bit or 32-bit sized type to contain it all. ** Are there any other known limitations of the compiler, or library suite? - length of identifier? - length of TEXT (ie, memory) - length of filenames, or pathname (some architectures may have differences, ie MS-Windows). o There should be a discussion of the @m3XXX runtime library command line options. o There should be an EXAMPLE section, with example source code (Hello world), along with supporting m3makefile. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 01:18:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 00:18:20 +0000 Subject: [M3devel] threads are broken on Windows In-Reply-To: <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> References: <4B16A059.1E75.00D7.1@scires.com>, <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> Message-ID: That's wierd, but I do see it occuring too. Will look later. - Jay From: hosking at cs.purdue.edu Date: Wed, 2 Dec 2009 17:21:49 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] threads are broken on Windows Jay's call on that one... On 2 Dec 2009, at 17:17, Randy Coleburn wrote: Something is wrong with threads on Windows from the HEAD branch. After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 12:09:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 11:09:53 +0000 Subject: [M3devel] processing stack/context Message-ID: Tony, it looks like you assume the context passed to a signal handler is on the stack. Is that really guaranteed? It couldn't be in some thread local for some reason? (signals can nest? Therefore that would be problematic?) We can just use the address of a local, right? And we can assume the signal stack is the regular stack? By default? (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 3 16:05:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Dec 2009 10:05:33 -0500 Subject: [M3devel] processing stack/context In-Reply-To: References: Message-ID: <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Actually, in the latest version I explicitly process the signal context as well as the stack. On 3 Dec 2009, at 06:09, Jay K wrote: > Tony, it looks like you assume the context passed to a signal handler is on the stack. > Is that really guaranteed? It couldn't be in some thread local for some reason? > (signals can nest? Therefore that would be problematic?) > We can just use the address of a local, right? > > And we can assume the signal stack is the regular stack? > By default? > (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) > > I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 19:33:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 18:33:03 +0000 Subject: [M3devel] processing stack/context In-Reply-To: <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> References: , <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Message-ID: Tony, Understood, but you use the context as one end of the stack. void ThreadPThread__ProcessStopped (m3_pthread_t mt, char *bottom, char *context, void (*p)(void *start, void *limit)) { /* process stack */ if (stack_grows_down) { assert(context < bottom); p(context, bottom); here } else { assert(bottom < context); p(bottom, context); here } /* process register context */ p(context, context + sizeof(ucontext_t)); } - Jay From: hosking at cs.purdue.edu Date: Thu, 3 Dec 2009 10:05:33 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] processing stack/context Actually, in the latest version I explicitly process the signal context as well as the stack. On 3 Dec 2009, at 06:09, Jay K wrote: Tony, it looks like you assume the context passed to a signal handler is on the stack. Is that really guaranteed? It couldn't be in some thread local for some reason? (signals can nest? Therefore that would be problematic?) We can just use the address of a local, right? And we can assume the signal stack is the regular stack? By default? (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 3 20:02:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Dec 2009 14:02:34 -0500 Subject: [M3devel] processing stack/context In-Reply-To: References: , <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Message-ID: <9C163B67-026B-48CD-B6D0-1C54D7910166@cs.purdue.edu> Ah, yes, understood. I think in general one can assume that the signal handler context is on the actual stack (we are not using sigaltstack here), but yes it might be safer to explicitly extract a "top" value in the signal handler, independently of the context and pass it in as another parameter to ProcessStopped. 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 3 Dec 2009, at 13:33, Jay K wrote: > Tony, Understood, but you use the context as one end of the stack. > > void > ThreadPThread__ProcessStopped (m3_pthread_t mt, char *bottom, char *context, > void (*p)(void *start, void *limit)) > { > /* process stack */ > if (stack_grows_down) { > assert(context < bottom); > p(context, bottom); here > } else { > assert(bottom < context); > p(bottom, context); here > } > /* process register context */ > p(context, context + sizeof(ucontext_t)); > } > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 3 Dec 2009 10:05:33 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] processing stack/context > > Actually, in the latest version I explicitly process the signal context as well as the stack. > > On 3 Dec 2009, at 06:09, Jay K wrote: > > Tony, it looks like you assume the context passed to a signal handler is on the stack. > Is that really guaranteed? It couldn't be in some thread local for some reason? > (signals can nest? Therefore that would be problematic?) > We can just use the address of a local, right? > > And we can assume the signal stack is the regular stack? > By default? > (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) > > I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 22:20:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 21:20:32 +0000 Subject: [M3devel] ThreadWin32/LockMutex/giantLock/alertable? Message-ID: It'd be good to remove the giantLock from LockMutex/UnlockMutex. Mutexes can be replaced, like in Java, with just interlocked+semaphore -- no wait list (the semaphore would have an implicit wait list) -- or similarly just a Win32 critical section. I believe the inefficieny of ThreadWin32 having a "giantLock" need not impact folks only using locks -- it is only needed when acting on condition variables, and /possibly/ alert/alertwait (but probably not). In looking at it, something that bugs me is "act.alertable := FALSE". That can be outside the lock? Or remove entirely? And/or moved to before "RAISE Alerted"? Or for that matter, AlertWait should always exit with it false? And Wait should always assert it true? And there's some redundancy there. Basically, it should always be FALSE unless within AlertWait? I'm pretty sure those later options -- alertable is generally false, and writes only need to occur within AlertWait to make it temporarily true. LockMutex could just assert that it is false. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 10:00:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 09:00:27 +0000 Subject: [M3devel] FW: some open bugs In-Reply-To: <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 12:48:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 11:48:46 +0000 Subject: [M3devel] DateBsd.m3 lock usually not needed Message-ID: It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:06:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:06:45 +0000 Subject: [M3devel] some open bugs In-Reply-To: <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: In head: https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) doesn't occur jbook2:bin jay$ /cm3.amd64/bin/cm3 ? --- building in AMD64_DARWIN --- Fatal Error: unsupported file type "?" Perhaps should print usage. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Mixed. https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between doesn't occur There is this: m3-sys/windowsResources/AMD64_DARWIN/.M3SHIP seems to be broken: make_dir("/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib") symbolic_link_file("libwindowsResources.5.2.dylib", "/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib/libwindowsResources.dylib") symbolic_link_file("libwindowsResources.5.2.dylib", "/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib/libwindowsResources.5.dylib") Which I understand in general, haven't looked at it here. I'm not too blame for all the funny characters in "tmp". Apple does that. Need to test release. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: FW: some open bugs Date: Sun, 6 Dec 2009 09:00:27 +0000 > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:18:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:18:39 +0000 Subject: [M3devel] formsedit AMD64_DARWIN unslotted thread Message-ID: Tony, somtimes, like one in ten, starting up, AMD64_DARWIN, formsedit, head. Maybe worth trying a simpler AssignSlot? (gdb) r Starting program: /private/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-/cm3/bin/formsedit warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries +++++++++++++++++..... done *** *** runtime error: *** Thread client error: unslotted thread! *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 349 *** Program received signal SIGABRT, Aborted. 0x00007fff83416e3e in semaphore_wait_signal_trap () (gdb) thread apply all bt Thread 8 (process 54920 thread 0x2693): #0 0x00007fff834e06be in __semwait_signal_nocancel () #1 0x00007fff834e02f4 in nanosleep$NOCANCEL () #2 0x00007fff834da404 in usleep$NOCANCEL () #3 0x00007fff834eef77 in abort () #4 0x00000001009acbe1 in Cstdlib__abort () #5 0x00000001009a2eea in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #6 0x0000000100996e64 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #7 0x000000010099457d in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #8 0x0000000100994229 in RTError__Msg (M3_Bd56fi_file=0x1009f5fb0, M3_AcxOUs_line=349, M3_Bd56fi_msgA=0x1009f5ff0, M3_Bd56fi_msgB=0x1009f5b88, M3_Bd56fi_msgC=0x0) at ../src/runtime/common/RTError.m3:23 #9 0x00000001009a97fe in ThreadPThread__Die (M3_AcxOUs_lineno=349, M3_Bd56fi_msg=0x1009f5b88) at ../src/thread/PTHREAD/ThreadPThread.m3:1245 #10 0x00000001009a5fe1 in ThreadPThread__FreeSlot (M3_BXP32l_t=0x102259910) at ../src/thread/PTHREAD/ThreadPThread.m3:349 #11 0x00000001009a6b1c in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101635220) at ../src/thread/PTHREAD/ThreadPThread.m3:486 #12 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101635220) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #13 0x00007fff83444e8b in _pthread_start () #14 0x00007fff83444d4d in thread_start () Thread 7 (process 54920 thread 0x2707): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x10162c590, M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257210, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257210) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x00000001003b17fa in XMessenger__Messenger (M3_EVlqQO_self=0x1015d23a8) at ../src/xvbt/XMessenger.m3:69 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c590) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c590) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 6 (process 54920 thread 0x240b): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x10162c480, M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257250, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257250) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x00000001003c1167 in XInput__FilterXInput (M3_DSd60P_self=0x1015d2330) at ../src/xvbt/XInput.m3:102 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c480) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c480) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 5 (process 54920 thread 0x250b): #0 0x00007fff83462582 in select$DARWIN_EXTSN () #1 0x00000001009ab82d in Unix__select () #2 0x00000001009a7e88 in ThreadPThread__XIOWait__CallSelect.1153 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:677 #3 0x00000001009a7b20 in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:716 #4 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:619 #5 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x1015d22b8) at ../src/xvbt/XInput.m3:63 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 4 (process 54920 thread 0x2103): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5ef in ThreadPThread__pthread_cond_timedwait () #3 0x00000001009a72d9 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1016185f0, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:575 #4 0x00000001009a73b5 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:590 #5 0x0000000100075ab2 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:259 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 3 (process 54920 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 54920 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5ef in ThreadPThread__pthread_cond_timedwait () #3 0x00000001009a72d9 in ThreadPThread__XPause (M3_DMxDjQ_self=0x101618080, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:575 #4 0x00000001009a73b5 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:590 #5 0x00000001004090cf in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:460 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 54920 local thread 0x2e03): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a570d in ThreadPThread__AssignSlot (M3_BXP32l_t=0x1021cc0b0) at ../src/thread/PTHREAD/ThreadPThread.m3:301 #4 0x00000001009a6516 in ThreadPThread__CreateT (M3_DMxDjQ_act=0x1016353b0) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #5 0x00000001009a6b72 in Thread__Fork (M3_EMTrVz_closure=0x1015b1990) at ../src/thread/PTHREAD/ThreadPThread.m3:496 #6 0x000000010040a402 in VBTRep__Mark (M3_BFdKo9_v=0x1021fe380) at ../src/vbt/VBTRep.m3:587 #7 0x00000001003fcedf in VBT__Mark (M3_BFdKo9_v=0x1021fe380) at ../src/vbt/VBT.m3:1247 #8 0x000000010042ee00 in HVSplit__NewShape (M3_ABI5Rn_v=0x1021fe380, M3_BFdKo9_ch=0x1022002d8) at ../src/split/HVSplit.m3:487 #9 0x00000001003fcbd3 in VBT__NewShape (M3_BFdKo9_v=0x1022002d8) at ../src/vbt/VBT.m3:1225 #10 0x000000010007d2ad in FlexVBT__Rescreen (M3_BpJoz9_v=0x1022002d8, M3_BpW0LT_cd=0x7fff5fbfc800) at ../src/lego/FlexVBT.m3:101 #11 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1022002d8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #12 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fe380, M3_BpW0LT_cd=0x7fff5fbfc990) at ../src/vbt/VBTClass.m3:751 #13 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fe380, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #14 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fcbb8, M3_BpW0LT_cd=0x7fff5fbfcb20) at ../src/vbt/VBTClass.m3:751 #15 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fcbb8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #16 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fc018, M3_BpW0LT_cd=0x7fff5fbfcd20) at ../src/vbt/VBTClass.m3:751 #17 0x0000000100429b6d in BorderedVBT__Rescreen (M3_C4s4Wp_v=0x1021fc018, M3_BpW0LT_cd=0x7fff5fbfcd20) at ../src/split/BorderedVBT.m3:157 #18 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fc018, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #19 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb4e8, M3_BpW0LT_cd=0x7fff5fbfcee0) at ../src/vbt/VBTClass.m3:751 #20 0x000000010007d2a4 in FlexVBT__Rescreen (M3_BpJoz9_v=0x1021fb4e8, M3_BpW0LT_cd=0x7fff5fbfcee0) at ../src/lego/FlexVBT.m3:100 #21 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb4e8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #22 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa248, M3_BpW0LT_cd=0x7fff5fbfd070) at ../src/vbt/VBTClass.m3:751 #23 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa248, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #24 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb410, M3_BpW0LT_cd=0x7fff5fbfd230) at ../src/vbt/VBTClass.m3:751 #25 0x00000001000a675f in ShadowedVBT__Rescreen (M3_AyFi3t_v=0x1021fb410, M3_BpW0LT_cd=0x7fff5fbfd230) at ../src/lego/ShadowedVBT.m3:86 #26 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb410, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #27 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fbe00, M3_BpW0LT_cd=0x7fff5fbfd3c0) at ../src/vbt/VBTClass.m3:751 #28 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fbe00, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #29 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb330, M3_BpW0LT_cd=0x7fff5fbfd5c0) at ../src/vbt/VBTClass.m3:751 #30 0x0000000100429b6d in BorderedVBT__Rescreen (M3_C4s4Wp_v=0x1021fb330, M3_BpW0LT_cd=0x7fff5fbfd5c0) at ../src/split/BorderedVBT.m3:157 #31 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb330, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #32 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa160, M3_BpW0LT_cd=0x7fff5fbfd810) at ../src/vbt/VBTClass.m3:751 #33 0x0000000100451530 in StableVBT__Rescreen (M3_CStG2l_w=0x1021fa160, M3_BpW0LT_cd=0x7fff5fbfd810) at ../src/split/StableVBT.m3:115 #34 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa160, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #35 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa018, M3_BpW0LT_cd=0x7fff5fbfda00) at ../src/vbt/VBTClass.m3:751 #36 0x00000001000b2711 in ZChildVBT__Rescreen (M3_EF20wQ_v=0x1021fa018, M3_BpW0LT_cd=0x7fff5fbfda00) at ../src/lego/ZChildVBT.m3:127 #37 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa018, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #38 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1015aea90, M3_BpW0LT_cd=0x7fff5fbfdc10) at ../src/vbt/VBTClass.m3:751 #39 0x0000000100432804 in ZSplit__Rescreen (M3_COSw3M_v=0x1015aea90, M3_BpW0LT_cd=0x7fff5fbfdc10) at ../src/split/ZSplit.m3:235 #40 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1015aea90, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #41 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8970, M3_BpW0LT_cd=0x7fff5fbfddd0) at ../src/vbt/VBTClass.m3:751 #42 0x000000010007d2a4 in FlexVBT__Rescreen (M3_BpJoz9_v=0x1021f8970, M3_BpW0LT_cd=0x7fff5fbfddd0) at ../src/lego/FlexVBT.m3:100 #43 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8970, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #44 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8858, M3_BpW0LT_cd=0x7fff5fbfdf60) at ../src/vbt/VBTClass.m3:751 #45 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8858, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #46 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8770, M3_BpW0LT_cd=0x7fff5fbfe0f0) at ../src/vbt/VBTClass.m3:751 #47 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8770, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #48 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x101799158, M3_BpW0LT_cd=0x7fff5fbfe300) at ../src/vbt/VBTClass.m3:751 #49 0x0000000100432804 in ZSplit__Rescreen (M3_COSw3M_v=0x101799158, M3_BpW0LT_cd=0x7fff5fbfe300) at ../src/split/ZSplit.m3:235 #50 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x101799158, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #51 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1015b7918, M3_BpW0LT_cd=0x7fff5fbfe490) at ../src/vbt/VBTClass.m3:751 #52 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1015b7918, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #53 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b9858, M3_BpW0LT_cd=0x7fff5fbfe650) at ../src/vbt/VBTClass.m3:751 #54 0x0000000100469d11 in InstalledVBT__Rescreen (M3_BnDICA_v=0x1024b9858, M3_BpW0LT_cd=0x7fff5fbfe650) at ../src/trestle/InstalledVBT.m3:77 #55 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b9858, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #56 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b9948, M3_BpW0LT_cd=0x7fff5fbfe8a0) at ../src/vbt/VBTClass.m3:751 #57 0x0000000100451530 in StableVBT__Rescreen (M3_CStG2l_w=0x1024b9948, M3_BpW0LT_cd=0x7fff5fbfe8a0) at ../src/split/StableVBT.m3:115 #58 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b9948, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #59 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b97a0, M3_BpW0LT_cd=0x7fff5fbfea80) at ../src/vbt/VBTClass.m3:751 #60 0x000000010045342f in JoinedVBT__Rescreen (M3_B2daE0_v=0x1024b97a0, M3_BpW0LT_cd=0x7fff5fbfea80) at ../src/split/JoinedVBT.m3:169 #61 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b97a0, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #62 0x0000000100457e68 in JoinParent__Be (M3_EjiMte_prntP=0x1024a08d0, M3_B2daE0_v=0x1024b97a0) at ../src/split/JoinParent.m3:309 #63 0x0000000100467485 in DpyFilter__Init (M3_AMerq9_v=0x1024a08d0, M3_B2daE0_ch=0x1024b97a0, M3_AicXUJ_enabled=1 '\001') at ../src/trestle/DpyFilter.m3:59 #64 0x00000001004699e1 in InstalledVBT__InitParent (M3_DaeRwb_res=0x1024a08d0, M3_Bli4Mk_ch=0x1024b97a0) at ../src/trestle/InstalledVBT.m3:49 #65 0x000000010046cee9 in Trestle__AddApp (M3_D5sYfW_a=0x1024a0878, M3_Arkhkf_cuser=0x1015d2460) at ../src/trestle/Trestle.m3:402 #66 0x000000010046c1a9 in Trestle__NoConfInit (M3_D5sYfW_a=0x1024a0878, M3_Arkhkf_u=0x1015d2460) at ../src/trestle/Trestle.m3:317 #67 0x000000010046caf1 in Trestle__InnerAttach (M3_BFdKo9_v=0x1015b7918, M3_DpX0S5_trsl=0x102256b38) at ../src/trestle/Trestle.m3:379 #68 0x000000010046c17b in Trestle__Attach (M3_BFdKo9_v=0x1015b7918, M3_DpX0S5_trsl=0x102256b38) at ../src/trestle/Trestle.m3:285 #69 0x0000000100008c58 in FormsEditVBT__Install (M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_editorGeo=0x100163230) at ../src/FormsEditVBT.m3:379 #70 0x0000000100007371 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:255 #71 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #72 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #73 0x000000010099385e in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #74 0x0000000100992ba2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #75 0x0000000100992c40 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #76 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff858, envp=0x7fff5fbff868) at _m3main.mc:4 (gdb) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 15:25:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 09:25:58 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: Message-ID: That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... 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 6 Dec 2009, at 06:48, Jay K wrote: > It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:29:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:29:29 +0000 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: , Message-ID: I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while switching is disabled? I came up with something a bit hacky but maybe ok. - Jay Subject: Re: [M3devel] DateBsd.m3 lock usually not needed From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 09:25:58 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... 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 On 6 Dec 2009, at 06:48, Jay K wrote:It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:31:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:31:13 +0000 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up Message-ID: formsedit startup seems to often hang in the debugger, in head. The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) (gdb) thread apply all bt Thread 7 (process 56120 thread 0x250b): #0 0x00007fffffe0027d in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 6 (process 56120 thread 0x240b): #0 0x00007fffffe00278 in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 5 (process 56120 thread 0x2707): #0 0x00007fffffe00296 in ?? () #1 0x00007fff83447ec2 in _pthread_lookup_thread () #2 0x00007fff83447e73 in pthread_mach_thread_np () #3 0x00000001009aa770 in ThreadPThread__SuspendThread () #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #18 0x00007fff83444e8b in _pthread_start () #19 0x00007fff83444d4d in thread_start () Thread 4 (process 56120 thread 0x2103): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #9 0x00007fff83444e8b in _pthread_start () #10 0x00007fff83444d4d in thread_start () Thread 3 (process 56120 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 56120 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 56120 local thread 0x2e03): #0 0x00007fff83444c48 in pthread_create () #1 0x00000001009aa2eb in ThreadPThread__thread_create () #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 (gdb) cont Continuing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 6 15:37:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Dec 2009 15:37:00 +0100 Subject: [M3devel] Hudson failures and outages, was: RE: solsun/solgnu In-Reply-To: References: , <20091129175131.3a9yckela8cgck0c@mail.elegosoft.com> Message-ID: <20091206153700.m98zvhh3dwwo04go@mail.elegosoft.com> Quoting Jay K : > There was also a problem with SOLgnu where a bad cm3 had been built > and gotten "stuck". > I cleaned up the various directories in the workspace and got it > working again. > (There's no evidence trail.) Great, thanks. I've had a more or less complete server crash here at home and had to get a new machine. I'm still busy reinstalling and recovering. Unfortunately, this is now also the step from 32 to 64 bits for my server, and most of the old programs/setups don't work out of the box. I'll probably need several more days until everything is in working order again. So luthien will probably not be available for FreeBSD4 builds. The good news is that I can now test the AMD64_FREEBSD stuff :-) 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 From jay.krell at cornell.edu Sun Dec 6 15:48:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:48:22 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head Message-ID: Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:51:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:51:34 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: Message-ID: I also saw I386_DARWIN Juno FreeSlot: z=0x2141c94 t=0xb038ced0 n_slotted=7 slots=0xb7909c t.act=0x22b8010 t.act.slot=14 *** *** runtime error: *** Thread client error: unslotted thread! *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 364 *** What I'll probably do over the next few days is test more PPC_DARWIN, LINUXLIBC6, Solaris, maybe some BSD, see where it occurs. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 6 Dec 2009 14:48:22 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:14:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:14:14 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: , Message-ID: <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> On 6 Dec 2009, at 09:29, Jay K wrote: > I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while > switching is disabled? Yes, it sure can. DisableSwitching/EnableSwitching is exactly what is needed whenever you are dealing with libraries that are not thread safe with the user-level thread-switching. > I came up with something a bit hacky but maybe ok. > > - Jay > > > Subject: Re: [M3devel] DateBsd.m3 lock usually not needed > From: hosking at cs.purdue.edu > Date: Sun, 6 Dec 2009 09:25:58 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... > > 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 6 Dec 2009, at 06:48, Jay K wrote: > > It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:16:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:16:51 -0500 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up In-Reply-To: References: Message-ID: Maybe related to the FreeSlot problem I just fixed? Please try with the latest. On 6 Dec 2009, at 09:31, Jay K wrote: > formsedit startup seems to often hang in the debugger, in head. > > The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. > I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) > > (gdb) thread apply all bt > > Thread 7 (process 56120 thread 0x250b): > #0 0x00007fffffe0027d in ?? () > #1 0x00007fff83444db7 in _pthread_start () > #2 0x00007fff83444d4d in thread_start () > > Thread 6 (process 56120 thread 0x240b): > #0 0x00007fffffe00278 in ?? () > #1 0x00007fff83444db7 in _pthread_start () > #2 0x00007fff83444d4d in thread_start () > > Thread 5 (process 56120 thread 0x2707): > #0 0x00007fffffe00296 in ?? () > #1 0x00007fff83447ec2 in _pthread_lookup_thread () > #2 0x00007fff83447e73 in pthread_mach_thread_np () > #3 0x00000001009aa770 in ThreadPThread__SuspendThread () > #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 > #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 > #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 > #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 > #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 > #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 > #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 > #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 > #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 > #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 > #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 > #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 > #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #18 0x00007fff83444e8b in _pthread_start () > #19 0x00007fff83444d4d in thread_start () > > Thread 4 (process 56120 thread 0x2103): > #0 0x00007fff83416e3e in semaphore_wait_signal_trap () > #1 0x00007fff8341e758 in pthread_mutex_lock () > #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () > #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 > #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 > #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 > #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 > #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #9 0x00007fff83444e8b in _pthread_start () > #10 0x00007fff83444d4d in thread_start () > > Thread 3 (process 56120 thread 0x2003): > #0 0x00007fff8341ddc2 in __semwait_signal () > #1 0x00007fff83445ca9 in _pthread_cond_wait () > #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () > #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 > #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #8 0x00007fff83444e8b in _pthread_start () > #9 0x00007fff83444d4d in thread_start () > > Thread 2 (process 56120 thread 0x313): > #0 0x00007fff8341ddc2 in __semwait_signal () > #1 0x00007fff83445ca9 in _pthread_cond_wait () > #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () > #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 > #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #8 0x00007fff83444e8b in _pthread_start () > #9 0x00007fff83444d4d in thread_start () > > Thread 1 (process 56120 local thread 0x2e03): > #0 0x00007fff83444c48 in pthread_create () > #1 0x00000001009aa2eb in ThreadPThread__thread_create () > #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 > #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 > #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 > #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 > #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 > #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 > #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 > #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 > #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 > #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 > #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 > #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 > #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 > #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 > (gdb) cont > Continuing. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:23:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:23:33 -0500 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: Message-ID: Please report back how things behave with the latest commit... On 6 Dec 2009, at 09:48, Jay K wrote: > Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). > > Here is the second crash > > (gdb) r > Starting program: /Users/jay/cm3/bin/Juno > Reading symbols for shared libraries +++++++++++++++++++++++..... done > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 > [Switching to process 79884 thread 0x29b7] > 0x01710774 in ?? () > (gdb) bt > #0 0x01710774 in ?? () > #1 0xb038cf28 in ?? () > Previous frame inner to this frame (gdb could not unwind past this frame) > (g > > > (gdb) thread apply all bt > > Thread 9 (process 79884 thread 0x27bf): > #0 0x968782ce in semaphore_wait_signal_trap () > #1 0x9687fda5 in pthread_mutex_lock () > #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () > #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 > #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 > #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 > #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #7 0x968a9155 in _pthread_start () > #8 0x968a9012 in thread_start () > > Thread 8 (process 79884 thread 0x29b7): > #0 0x01710774 in ?? () > #1 0xb038cf28 in ?? () > Previous frame inner to this frame (gdb could not unwind past this frame) > > Thread 7 (process 79884 thread 0x2603): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 6 (process 79884 thread 0x2507): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 5 (process 79884 thread 0x240f): > #0 0x968c76fa in select$DARWIN_EXTSN () > #1 0x00b524c3 in Unix__select () > #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 > #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 > #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 > #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 > #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #8 0x968a9155 in _pthread_start () > #9 0x968a9012 in thread_start () > > Thread 4 (process 79884 thread 0x2303): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () > #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () > #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 > #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 > #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 3 (process 79884 thread 0x2203): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 2 (process 79884 thread 0x1003): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () > #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () > #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 > #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 > #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 1 (process 79884 local thread 0x2e03): > #0 0x968782ce in semaphore_wait_signal_trap () > #1 0x9687fda5 in pthread_mutex_lock () > #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () > #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 > #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 > #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 > #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 > #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 > #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 > #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 > #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 > #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 > #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 > #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 > #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 > #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:54:46 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:54:46 -0500 Subject: [M3devel] FW: some open bugs In-Reply-To: References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: <4B1C34ED.1E75.00D7.1@scires.com> Hi Jay: Can you be more specific about the nature of the "windows C runtime version issue" you report below ? Regards, Randy >>> Jay K 12/6/2009 4:00 AM >>> > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:57:02 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:57:02 -0500 Subject: [M3devel] build problem diagnosis in caltech-parser test package References: <4B150A90020000D700067FB8@scires.com> Message-ID: <4B1C3575.1E75.00D7.1@scires.com> I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:59:15 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:59:15 -0500 Subject: [M3devel] Fwd: [M3commit] CVS Update: cm3 References: <20091201165512.EA71F2474001@birch.elegosoft.com> Message-ID: <4B1C35FA.1E75.00D7.1@scires.com> Is everyone ok with the edit I made here? If so, someone should promote this fix to the release branch. Also, Is there a reason we should limit this package to POSIX platforms? If not, we should take out the if statement at line 31 and the corresponding end. --Randy >>> Randy Coleburn 12/1/2009 5:55 PM >>> CVSROOT:/usr/cvs Changes by:rcoleburn at birch.09/12/01 17:55:12 Modified files: cm3/m3-tools/cvsup/suplib/src/: m3makefile Log message: add missing "end" statement at line 58 to correct compile-time syntax error. Someone needs to check me on this one. After this change, I don't get any packages built in cvsup on WindowsXP, I suppose due to some prerequiste not being met. But at least I don't get the syntax error. Not sure why the package m3makefile seems to be limited to POSIX platforms at line 31. Everything was building on Windows before.--R.Coleburn Here is the compiler output before my correction: C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES "C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args", line 5: quake runtime error: C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\src\m3makefile, line 263: syntax error: "end" or "else" expected after "if" --procedure-- -line- -file--- include_dir -- 5 C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.03 2 removing temporary files 0.03 other --------------------------------------------------- 0.06 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:44:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:44:02 +0000 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up In-Reply-To: References: , Message-ID: Yes better now thank you. - Jay Subject: Re: AMD64_DARWIN head formsedit sometimes hangs starting up From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 14:16:51 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Maybe related to the FreeSlot problem I just fixed? Please try with the latest. On 6 Dec 2009, at 09:31, Jay K wrote:formsedit startup seems to often hang in the debugger, in head. The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) (gdb) thread apply all bt Thread 7 (process 56120 thread 0x250b): #0 0x00007fffffe0027d in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 6 (process 56120 thread 0x240b): #0 0x00007fffffe00278 in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 5 (process 56120 thread 0x2707): #0 0x00007fffffe00296 in ?? () #1 0x00007fff83447ec2 in _pthread_lookup_thread () #2 0x00007fff83447e73 in pthread_mach_thread_np () #3 0x00000001009aa770 in ThreadPThread__SuspendThread () #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #18 0x00007fff83444e8b in _pthread_start () #19 0x00007fff83444d4d in thread_start () Thread 4 (process 56120 thread 0x2103): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #9 0x00007fff83444e8b in _pthread_start () #10 0x00007fff83444d4d in thread_start () Thread 3 (process 56120 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 56120 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 56120 local thread 0x2e03): #0 0x00007fff83444c48 in pthread_create () #1 0x00000001009aa2eb in ThreadPThread__thread_create () #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 (gdb) cont Continuing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:44:46 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: , Message-ID: Yes better. I think I had actually fixed it. The other problem was something related to pthread_self vs. the handle you get from pthread_create or something..I don't understand that part. - Jay Subject: Re: I386_DARWIN Juno crash/hang head From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 14:23:33 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Please report back how things behave with the latest commit... On 6 Dec 2009, at 09:48, Jay K wrote:Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:55:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:55:08 +0000 Subject: [M3devel] race condition setting act.handle? Message-ID: pthread_create(act.handle) followed at some point by use of act.handle in the new thread. Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. What is to cause act.handle to be stored before the new thread starts and uses act.handle? For this reason in Win32 I create the thread suspended, store the handle, resume the thread. Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 7 10:29:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Dec 2009 10:29:00 +0100 Subject: [M3devel] Fwd: [M3commit] CVS Update: cm3 In-Reply-To: <4B1C35FA.1E75.00D7.1@scires.com> References: <20091201165512.EA71F2474001@birch.elegosoft.com> <4B1C35FA.1E75.00D7.1@scires.com> Message-ID: <20091207102900.gohdo855sg8scw0g@mail.elegosoft.com> Quoting Randy Coleburn : > Is everyone ok with the edit I made here? If so, someone should > promote this fix to the release branch. > Also, Is there a reason we should limit this package to POSIX platforms? > If not, we should take out the if statement at line 31 and the > corresponding end. AFAIK CVSup never had any support for Windows platforms. For its optimizations it relies heavily on very Unix-specific functions. I'm not aware that this has changed, but could be wrong. If you find that subsets of the packages compile, we can surely add them for Windows targets, too. Olaf > --Randy > >>>> Randy Coleburn 12/1/2009 5:55 PM >>> > CVSROOT:/usr/cvs > Changes by:rcoleburn at birch.09/12/01 17:55:12 > > Modified files: > cm3/m3-tools/cvsup/suplib/src/: m3makefile > > Log message: > add missing "end" statement at line 58 to correct compile-time syntax error. > > Someone needs to check me on this one. After this change, I don't > get any packages built in cvsup on WindowsXP, I suppose due to some > prerequiste not being met. But at least I don't get the syntax error. > > Not sure why the package m3makefile seems to be limited to POSIX > platforms at line 31. Everything was building on Windows > before.--R.Coleburn > > Here is the compiler output before my correction: > > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib>cm3 -verbose > EVAL ("C:\cm3\bin\cm3.cfg") > --- building in NT386 --- > > cd NT386 > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > EVAL ("m3make.args") > rm .M3SHIP > rm .M3OVERRIDES > "C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args", line > 5: quake runtime error: > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\src\m3makefile, line 263: > syntax error: "end" or "else" expected after "if" > > --procedure-- -line- -file--- > include_dir -- > 5 C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args > > Fatal Error: package build failed > > seconds #times operation > 0.03 2 removing temporary files > 0.03 other > --------------------------------------------------- > 0.06 TOTAL > > rm m3make.args > cd .. > > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib> > > -- 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 From peter.mckinna at gmail.com Mon Dec 7 12:17:50 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 7 Dec 2009 22:17:50 +1100 Subject: [M3devel] AutoFlushWr race. Message-ID: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> Hi, I thought I would have a try at fixing the problem in AutoFlushWr with the little program below. Alas I couldnt get a grip on it so maybe you guys could shed some light. This was with RC4 and on an amd64 linux box. It invariably crashes in FileWr.Seek where some invariant seems to be awry so obviously the worker thread created in AutoFlushWr is hitting or causing a race condition. Probably easily fixed. The thing that intrigued me was that most of the time running it did not cause the normal crash sequence and I had to ctrl-c to get back to the bash prompt which judging from the stack trace something in the threads area is amiss. Regards Peter MODULE Main; IMPORT FileWr,Wr,Rd,AutoFlushWr,Stdio,IO,Fmt,Thread; VAR myout := NEW(AutoFlushWr.T).init(Stdio.stdout); BEGIN FOR i := 0 TO 10000 DO Wr.PutText(myout,Fmt.Int(i) & "\n"); END; (* Thread.Pause(1.0D0); IO.Put("hit enter to end\n"); *) EVAL Rd.GetChar(Stdio.stdin); END Main. ... some iterations and 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) thread apply all bt Thread 3 (Thread 1106278736 (LWP 5197)): #0 0x00007f1a8b9ead29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f1a8bef8d4f in ThreadPThread__pthread_cond_wait (cond=0x24d0170, mutex=0x24d0770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007f1a8bef1ce0 in XWait (self=16_00000000024f2a48, m=16_00000000024ef030, c=16_00000000024ef0b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007f1a8bef214d in Wait (m=16_00000000024ef030, c=16_00000000024ef0b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007f1a8c9e2c62 in Worker (cl=16_00000000024f2a38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007f1a8bef4447 in RunThread (me=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007f1a8bef4140 in ThreadBase (param=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007f1a8b9e6fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007f1a8b75c5ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 139752010405600 (LWP 5194)): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 ---Type to continue, or q to quit--- #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () Thread 1 (LWP 5194): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= ---Type to continue, or q to quit--- RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) Now why is the stack trace duplicated for Thread 1 and Thread 2 and also why is there that last line #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 in the last frame? The first and last frame are duplicated. Havent seen it in other stack traces. Maybe something wrong with my setup? running once more we get ....... some iterations 4311 4312 4313 4314 4315 4316 4317 4318 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** OK here I had to ctrl-c it since it is hung ^C Program received signal SIGINT, Interrupt. 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 (m3gdb) thread apply all bt Thread 3 (Thread 1113143632 (LWP 5200)): #0 0x00007fd82e654d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007fd82eb62d4f in ThreadPThread__pthread_cond_wait (cond=0x19a9170, mutex=0x19a9770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007fd82eb5bce0 in XWait (self=16_00000000019caa48, m=16_00000000019c7030, c=16_00000000019c70b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007fd82eb5c14d in Wait (m=16_00000000019c7030, c=16_00000000019c70b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007fd82f64cc62 in Worker (cl=16_00000000019caa38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007fd82eb5e447 in RunThread (me=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007fd82eb5e140 in ThreadBase (param=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007fd82e650fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007fd82e3c65ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 140566490150624 (LWP 5198)): #0 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007fd82e652bf0 in _L_lock_102 () from /lib/libpthread.so.0 ../../gdb/gdb/dwarf2-frame.c:490: internal-error: Unknown CFI encountered. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Is this a problem with m3gdb? Running this program without the debugger more likely than not will produce a hung program, so I suspect some threading problem. That lll_lock_wait is definitely suspicious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:36:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:36:02 +0000 Subject: [M3devel] AutoFlushWr race. In-Reply-To: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> References: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> Message-ID: Thank you for looking into stuff Peter. We really need more help. Can you try again either with head or the release commit I just did? Thanks. See: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw/AutoFlushWr.m3 etc. Thanks, - Jay Date: Mon, 7 Dec 2009 22:17:50 +1100 From: peter.mckinna at gmail.com To: m3devel at elegosoft.com Subject: [M3devel] AutoFlushWr race. Hi, I thought I would have a try at fixing the problem in AutoFlushWr with the little program below. Alas I couldnt get a grip on it so maybe you guys could shed some light. This was with RC4 and on an amd64 linux box. It invariably crashes in FileWr.Seek where some invariant seems to be awry so obviously the worker thread created in AutoFlushWr is hitting or causing a race condition. Probably easily fixed. The thing that intrigued me was that most of the time running it did not cause the normal crash sequence and I had to ctrl-c to get back to the bash prompt which judging from the stack trace something in the threads area is amiss. Regards Peter MODULE Main; IMPORT FileWr,Wr,Rd,AutoFlushWr,Stdio,IO,Fmt,Thread; VAR myout := NEW(AutoFlushWr.T).init(Stdio.stdout); BEGIN FOR i := 0 TO 10000 DO Wr.PutText(myout,Fmt.Int(i) & "\n"); END; (* Thread.Pause(1.0D0); IO.Put("hit enter to end\n"); *) EVAL Rd.GetChar(Stdio.stdin); END Main. ... some iterations and 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) thread apply all bt Thread 3 (Thread 1106278736 (LWP 5197)): #0 0x00007f1a8b9ead29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f1a8bef8d4f in ThreadPThread__pthread_cond_wait (cond=0x24d0170, mutex=0x24d0770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007f1a8bef1ce0 in XWait (self=16_00000000024f2a48, m=16_00000000024ef030, c=16_00000000024ef0b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007f1a8bef214d in Wait (m=16_00000000024ef030, c=16_00000000024ef0b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007f1a8c9e2c62 in Worker (cl=16_00000000024f2a38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007f1a8bef4447 in RunThread (me=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007f1a8bef4140 in ThreadBase (param=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007f1a8b9e6fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007f1a8b75c5ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 139752010405600 (LWP 5194)): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 ---Type to continue, or q to quit--- #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () Thread 1 (LWP 5194): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= ---Type to continue, or q to quit--- RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) Now why is the stack trace duplicated for Thread 1 and Thread 2 and also why is there that last line #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 in the last frame? The first and last frame are duplicated. Havent seen it in other stack traces. Maybe something wrong with my setup? running once more we get ....... some iterations 4311 4312 4313 4314 4315 4316 4317 4318 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** OK here I had to ctrl-c it since it is hung ^C Program received signal SIGINT, Interrupt. 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 (m3gdb) thread apply all bt Thread 3 (Thread 1113143632 (LWP 5200)): #0 0x00007fd82e654d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007fd82eb62d4f in ThreadPThread__pthread_cond_wait (cond=0x19a9170, mutex=0x19a9770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007fd82eb5bce0 in XWait (self=16_00000000019caa48, m=16_00000000019c7030, c=16_00000000019c70b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007fd82eb5c14d in Wait (m=16_00000000019c7030, c=16_00000000019c70b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007fd82f64cc62 in Worker (cl=16_00000000019caa38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007fd82eb5e447 in RunThread (me=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007fd82eb5e140 in ThreadBase (param=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007fd82e650fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007fd82e3c65ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 140566490150624 (LWP 5198)): #0 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007fd82e652bf0 in _L_lock_102 () from /lib/libpthread.so.0 ../../gdb/gdb/dwarf2-frame.c:490: internal-error: Unknown CFI encountered. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Is this a problem with m3gdb? Running this program without the debugger more likely than not will produce a hung program, so I suspect some threading problem. That lll_lock_wait is definitely suspicious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:48:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:48:15 +0000 Subject: [M3devel] race condition setting act.handle? Message-ID: I think I resolved this in a simple efficient manner. Please take a look. Perhaps pthread_create is guaranteed to write back the pthread_t before the code runs though? Win32 isn't as amenable to the efficiency here due to the division between handles and thread ids. pthread I'm not really so familiar with, not sure of the efficiency. In particular, where pthreads has pthread_self(), Win32 has three analogs: GetCurrentThreadId() GetCurrentThread() DuplicateHandle(GetCurrentThread()...) GetCurrentThread and GetCurrentThreadId are both fast -- no kernel call. However you can't do all that much with their results, e.g. you can't Suspend/Resume/Close/Wait. GetCurrentThread returns a special /constant/ that always means the current thread, relative to the caller. DuplicateHandle(GetCurrentThread()...) gives you something you can Suspend/Resume/Close/Wait but of course is slower, a kernel call. I have to pay for either the DuplicateHandle or ResumeThread, a wash. pthreads just has the one pthread_self. Fast? I don't know. A kernel call? I don't know. Usable with suspend/resume (np)? Yes. Well on Solaris it is fast: -bash-3.00$ /usr/ccs/bin/dis -F pthread_self /usr/lib/libc.so disassembly for /usr/lib/libc.so thr_self() thr_self: 81 c3 e0 08 retl thr_self+0x4: d0 01 e0 98 ld [%g7 + 0x98], %o0 Recent Linux/x86 is fast: objdump -d /usr/lib/libpthread_a 00001020 <__pthread_self>: 1020: 55 push %ebp 1021: 89 e5 mov %esp,%ebp 1023: 65 a1 50 00 00 00 mov %gs:0x50,%eax 1029: 5d pop %ebp 102a: c3 ret 102b: 90 nop 102c: 8d 74 26 00 lea 0x0(%esi),%esi (geez though, six instructions where only two are needed, crazy..imagine if all code was unoptimal by that factor...) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Subject: race condition setting act.handle? Date: Mon, 7 Dec 2009 06:55:08 +0000 pthread_create(act.handle) followed at some point by use of act.handle in the new thread. Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. What is to cause act.handle to be stored before the new thread starts and uses act.handle? For this reason in Win32 I create the thread suspended, store the handle, resume the thread. Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:49:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:49:40 +0000 Subject: [M3devel] truncation test Message-ID: truncation test. There is content after this line but I bet it won't show. . I bet this won't show up. Let's see. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:49:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:49:00 +0000 Subject: [M3devel] AutoFlushWr race. In-Reply-To: References: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com>, Message-ID: We're still getting emails truncated. Thank you for looking into stuff Peter. We really need more help. Can you try again either with head or the release commit I just did? Thanks. See: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw/AutoFlushWr.m3 etc. Thanks, - Jay > From: jay.krell at cornell.edu > To: peter.mckinna at gmail.com; m3devel at elegosoft.com > Date: Mon, 7 Dec 2009 12:36:02 +0000 > Subject: Re: [M3devel] AutoFlushWr race. > > > Thank you for looking into stuff Peter. We really need more help. > > Can you try again either with head or the release commit I just did? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:04:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:04:30 +0000 Subject: [M3devel] (please ignore, sorry, there will be a few of these) truncation test (65) Message-ID: (please ignore, sorry, there will be a few of these) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:56 +0000 Subject: [M3devel] truncation test (70) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:29 +0000 Subject: [M3devel] truncation test (66) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:04 +0000 Subject: [M3devel] truncation test (65b) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:06:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:06:34 +0000 Subject: [M3devel] truncation test (74) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 123456789012345678901234567890123456789012345678901234567890123456789012345 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:07:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:07:03 +0000 Subject: [M3devel] truncation test (76) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:08:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:08:11 +0000 Subject: [M3devel] truncation test (75) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:09:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:09:30 +0000 Subject: [M3devel] truncation test (77) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:10:55 +0000 Subject: [M3devel] truncation test (80) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:15:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:15:21 +0000 Subject: [M3devel] m3devel email truncation Message-ID: Here are two ways to get email truncated: 1) have a line that contains only a period; I noticed that happened to Tony not long ago, and I can make it happen deliberately. 2) Have a period in column 76. It happened to me in an email about autoflush and I can also make that happen deliberately. Beyond column 76 is ok. Olaf had mentioned it being something about periods. Perhaps I should be sure to yell! or be uncertain? :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:35:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:35:06 +0000 Subject: [M3devel] build problem diagnosis in caltech-parser test package In-Reply-To: <4B1C3575.1E75.00D7.1@scires.com> References: <4B150A90020000D700067FB8@scires.com>, <4B1C3575.1E75.00D7.1@scires.com> Message-ID: Randy, There is a recurring pattern in the tree related to this. Buildlocal (with overrides) should use the unshipped binary. Because nothing is being shipped. buildship (without overrides) should use the shipped binary. Because things are being shipped right after they are built, or you are using already shipped stuff -- same thing really. (All tools need to be built standalone, in order for the buildlocal version to work. Depending -- $ORIGIN is not compatible with running unshipped binaries. Using full paths is, but requires knowing the paths at link time and linking differently depending on if you are going to run from build_dir or installdir.) To see this in action, search for "override" in *tmpl files. stubgen for example works this. This is probably something that needs more automatic handling? See here: C:\dev2\cm3.2\m3-comm\netobj\src\netobj-ov.tmpl C:\dev2\cm3.2\m3-comm\netobj\src\netobj.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj-ov.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj.tmpl and then very important: C:\dev2\cm3.2\m3-comm\sharedobj\src\m3overrides C:\dev2\cm3.2\m3-comm\netobj\src\m3overrides I have a strong suspicion as well that sharedobj\src\m3overrides and netobj\src\m3overrides should be included in the central m3overrides. (and a strong suspicion as well, as I've said, that this mechanism is flawed; a better implementation I suspect is to /always/ ship, but either on top of the running system, or not to the running system, and then if "not to the running system" passes tests, swap them or move the one to the other, etc.) - Jay Date: Sun, 6 Dec 2009 22:57:02 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problem diagnosis in caltech-parser test package I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Mon Dec 7 14:41:38 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Mon, 07 Dec 2009 14:41:38 +0100 Subject: [M3devel] m3devel email truncation In-Reply-To: References: Message-ID: <20091207144138.u5xm8nkwkk4scogg@mail.elegosoft.com> Ok, thanks, I'll look into it. Mike Quoting Jay K : > > Here are two ways to get email truncated: > > > > 1) have a line that contains only a period; I noticed that > > happened to Tony not long ago, and I can make it happen deliberately. > > > > 2) Have a period in column 76. > > It happened to me in an email about autoflush and I can also > > make that happen deliberately. Beyond column 76 is ok. > > > > Olaf had mentioned it being something about periods. > > > > Perhaps I should be sure to yell! or be uncertain? :) > > > > - Jay > > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Dec 7 15:17:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 14:17:46 +0000 Subject: [M3devel] build problem diagnosis in caltech-parser test package In-Reply-To: References: <4B150A90020000D700067FB8@scires.com>, <4B1C3575.1E75.00D7.1@scires.com>, Message-ID: I guess I should point out that cm3, cm3cg, mklib, the config files are all handled "incorrectly" here. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 7 Dec 2009 13:35:06 +0000 Subject: Re: [M3devel] build problem diagnosis in caltech-parser test package Randy, There is a recurring pattern in the tree related to this. Buildlocal (with overrides) should use the unshipped binary. Because nothing is being shipped. buildship (without overrides) should use the shipped binary. Because things are being shipped right after they are built, or you are using already shipped stuff -- same thing really. (All tools need to be built standalone, in order for the buildlocal version to work. Depending -- $ORIGIN is not compatible with running unshipped binaries. Using full paths is, but requires knowing the paths at link time and linking differently depending on if you are going to run from build_dir or installdir.) To see this in action, search for "override" in *tmpl files. stubgen for example works this. This is probably something that needs more automatic handling? See here: C:\dev2\cm3.2\m3-comm\netobj\src\netobj-ov.tmpl C:\dev2\cm3.2\m3-comm\netobj\src\netobj.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj-ov.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj.tmpl and then very important: C:\dev2\cm3.2\m3-comm\sharedobj\src\m3overrides C:\dev2\cm3.2\m3-comm\netobj\src\m3overrides I have a strong suspicion as well that sharedobj\src\m3overrides and netobj\src\m3overrides should be included in the central m3overrides. (and a strong suspicion as well, as I've said, that this mechanism is flawed; a better implementation I suspect is to /always/ ship, but either on top of the running system, or not to the running system, and then if "not to the running system" passes tests, swap them or move the one to the other, etc.) - Jay Date: Sun, 6 Dec 2009 22:57:02 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problem diagnosis in caltech-parser test package I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 7 15:27:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Dec 2009 15:27:14 +0100 Subject: [M3devel] m3devel email truncation In-Reply-To: References: Message-ID: <20091207152714.rt753229gkww4ccc@mail.elegosoft.com> Quoting Jay K : > Here are two ways to get email truncated: > > 1) have a line that contains only a period; I noticed that > > happened to Tony not long ago, and I can make it happen deliberately. > > 2) Have a period in column 76. > > It happened to me in an email about autoflush and I can also > make that happen deliberately. Beyond column 76 is ok. > > Olaf had mentioned it being something about periods. A period alone on a line is an ancient convention for EOF (from the ages when terminals with serial lines connected via 2400 or 9600 baud were in common use). The mail servers here at NSN do the same thing still (ignore everything after a period :-). I don't think it is required by any standard (though I'm not sure here), and I assume it is buried deep in one of our filters/scripts/scanners which process the mails. So it may not be easy to locate. I'm not sure why column 76 should be special, though one could assume that's where wrapping text occurs so that the period is in column one on the next line. > Perhaps I should be sure to yell! or be uncertain? :) No need to yell; Mike will do his best. He's got many other tasks though... 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 From dabenavidesd at yahoo.es Mon Dec 7 17:03:45 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 7 Dec 2009 16:03:45 +0000 (GMT) Subject: [M3devel] Looking to update cm3 manual page. Message-ID: <611913.58311.qm@web23606.mail.ird.yahoo.com> Hi: probably you want to take look the DEBUG pragma of Cambridge Modula-3 cam3: http://web.archive.org/web/20040103230522/www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/m3.pdf or here http://web.archive.org/web/20040714091911/http://www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/index.html the pragmas explained there are actually documented to be in the sources of cm3 see history notes http://opencm3.net/about-cm3.html I think there is a table of compiler options for cam3 (page 54 and 55 which have some of it also listed in the cm3 -? message of the pdf document above) and of "pass 0" of it which are listed there on page 57. Page 56 have a list of pragmas ( http://web.archive.org/web/20050112061744/www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/node42.html#SECTION00630000000000000000 ) also see the traditional CM3 and DEC SRC pragma list (http://opencm3.net/doc/help/cm3/pragmas.html) but there isn't more information about <*INTRINSIC*> pragma than see http://opencm3.net/about-cm3.html I think there other DEC in-house pragmas which the cm3 sources inhereted and are not linked to the compiler process itself like PRAGMA SPEC <*SPEC ...*> (i.e. http://opencm3.net/doc/help/gen_html/libm3/src/sequence/Sequence.ig.html see doc in http://web.archive.org/web/19970605182158/www.research.digital.com/SRC/esc/Esc-speclang.html) and those of .lm3 Larch Modula-3 checking (they were in .lm3 files i.e m3-libs/m3core/src/text/Text.lm3 , I think compiler didn't handle it. but still there is a syntax grammar that can be used to build a syntax checker of it http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-72.html ). Another pragma that could be documented is the one present and explained in the documentation <*TRACE*>: http://apotheca.hpl.hp.com/ftp/pub/DEC/SRC/hypertext/Modula-3/user.html see source code in m3-sys/m3front/src/misc/Token.m3 and documentation in the SRC Modula-3 version 2.11 documentation: Hope this can be useful for the man page and improved documentation you can take in account --- El mi?, 2/12/09, Peter Eiserloh escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Looking to update cm3 manual page. > Para: "M3Devel" > Fecha: mi?rcoles, 2 de diciembre, 2009 12:01 > Hi all, > > It has been more than half a year since I last looked at > the > CM3 manual page. I am now looking at the it in > preparation > for the release of version 5.8, and noticing some > deficiencies. > > I asking for help in identifying any further places it is > lacking. > I can integrate any feedback into a revised manual page, > and > submit an updated version back to the archives. > > > Currently identified deficiencies: > > o The manual page should explicitly state which version of > the > compiler it documents. > > o The sub-section "Expected Directory Structure" needs a > better > discussion, especially an introduction. > > o The discussion of mode option "-ship" mentions > environment > variable CM3_INSTALL_ROOT, yet in cm3.cfg we set > INSTALL_ROOT > without the "CM3_" prefix. This should > be resolved. > > ** What is the exact meaning of these two? Is > one recognized > by the compiler, and the other by > the supporting quake > code? > > o The ENVIRONMENT section does not mention > CM3_INSTALL_ROOT > at all. Add a discussion about both > INSTALL_ROOT, and > CM3_INSTALL_ROOT. > > ** Am I missing any other environment variables? > > o Missing command line options for the compiler: > > - I currently have "-g", but no discussion of > -gstabs. > No discussion about not supporting DWARF (or > do we?). > > o Compiler unique language features, (i.e., pragmas). > The > reference books (Nelson, and Harbison) give a list > of > suggested pragmas. The manual page should list > the ones > supported by the CM3 compiler explicitly, and show > their > syntax. > > ** Can someone list for me the pragmas supported by > the > current (5.8.4) compiler. > > o Should list any limitations of either the compiler, or > the library suite provided with the compiler. > > > For example, the WIDECHAR is limited by its 16-bit > size > to only a portion of the unicode character set > (the basic multi lingual plane), whereas a unicode > character is 20-bits, and we would need either a > 24-bit or 32-bit sized type to contain it all. > > ** Are there any other known limitations of the > compiler, > or library suite? > - length of identifier? > - length of TEXT (ie, > memory) > - length of filenames, or > pathname > (some architectures > may have differences, > ie MS-Windows). > > o There should be a discussion of the @m3XXX runtime > library command line options. > > o There should be an EXAMPLE section, with example > source code (Hello world), along with supporting > m3makefile. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > > | > +--------------------------------------------------------+ > > > > From hosking at cs.purdue.edu Mon Dec 7 18:42:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Dec 2009 12:42:13 -0500 Subject: [M3devel] race condition setting act.handle? In-Reply-To: References: Message-ID: On 7 Dec 2009, at 01:55, Jay K wrote: > pthread_create(act.handle) followed at some point by use of act.handle in the new thread. > Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. Good question. Previously we had fork inside activeMu, which prevented the forked thread running until the parent release activeMu. Now we don't. Perhaps that was the problem. > > > What is to cause act.handle to be stored before the new thread starts and uses act.handle? > > > For this reason in Win32 I create the thread suspended, store the handle, resume the thread. > Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 9 14:15:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Dec 2009 13:15:47 +0000 Subject: [M3devel] full source paths in debug info? Message-ID: I'll check the archive..but..we should have full paths to source files in debug information. That is what you always get with C and C++ on Windows. I understand they aren't particularly useful when binaries are copied across machines. But they are very useful when they aren't. Real life scenario, the debugger shows me: 0012fc2c 0041fd50 stubgen!Formatter__PutText+0xc6 [..\src\formatter\Formatter.m3 @ 275] 0012fc98 00410192 stubgen!IntfStubCode__Header+0x90 [..\src\IntfStubCode.m3 @ 25] 0012fd78 00409444 stubgen!StubCode__GenStub+0x14b [..\src\StubCode.m3 @ 91] 0012fdc8 00409117 stubgen!AstToType__ProcessNetObj+0x1e7 [..\src\AstToType.m3 @123] 0012fe38 00422b2b stubgen!AstToType__OneStub+0x59e [..\src\AstToType.m3 @ 95] 0012fe88 00443305 stubgen!Main__DoRun+0x3db [..\src\Main.m3 @ 64] 0012febc 00422b99 stubgen!M3ToolFrame__Startup+0x87 [..\src\toolframe\M3ToolFrame.m3 @ 27] 0012fee0 0056c3f4 stubgen!Main_M3+0x35 [..\src\Main.m3 @ 76] 0012ff24 0056b9cc stubgen!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLinker.m3 @ 399] If we did things correctly, I'd just copy/paste these paths into the file.open dialog. Instead I get to be slower. Here is C++ for example: C:\dev2\cm3.2\m3-ui\zeus\NT386>type t.c int main() { __debugbreak(); } C:\dev2\cm3.2\m3-ui\zeus\NT386>cl -Zi t.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. C:\dev2\cm3.2\m3-ui\zeus\NT386>\bin\x86\cdb.exe -g t.exe t!main+0x3: 00401013 cc int 3 0:000> .lines Line number information will be loaded 0:000> u . t!main+0x3 [c:\dev2\cm3.2\m3-ui\zeus\nt386\t.c @ 3]: - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 9 15:16:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Dec 2009 14:16:51 +0000 Subject: [M3devel] deadlock in Win32 threads? Message-ID: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 9 17:13:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Dec 2009 11:13:03 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: Message-ID: <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 07:59:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 06:59:34 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 08:43:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 07:43:42 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, Message-ID: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 10 10:18:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Dec 2009 10:18:24 +0100 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> Quoting Jay K : > Hm. First, what changed is probably the movement of stuff from > traced to untraced?? > > Which makes it more efficient and more like pthreads. > > I might try putting that back. > > What I have now though, is that in T, Mutex, and Condition, I put an > integer field writeToBlahBlah. > > Every time before Lock(giant), whatever, t, m, c, I have I write to > that field. > > That drastically mitigates this problem and it goes away. I don't really feel confident with such solutions. Maybe I'm a bit old-fashioned, but I think that code like a threading subsystem should be completely understood and `correct' (according to all available means). In my experience it is almost impossible to _test_ the `correctness' of concurrent and concurrency implementations, as the next usage scenario or even a simple hardware upgrade will reveal one unsafe or unprotected critical region after the other. And reveal doesn't mean `point to' here, but just indicate that something must be wrong somewhere ;-) So to keep the good spirit of Modula-3, I'd really favour a simple and completely understandable implementation even if it has some performance drawbacks. Deadlock can be completely avoided if all critical resources are known and a well-defined locking order is heeded for each access. If there is only one code path that may use another order, this deadlock will occur earlier or later, preferably when there is also stress to get something else working for a milestone or a release. All this should not be misinterpreted to depreciate testing; but there can never be enough tests, and there is only a limited time to perform them regularly. Olaf > However that still leaves me with a similar deadlock. > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > This thread is stuck trying to get the heap lock. > > It is I presume "inCritical" already. > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > The first thread has the heap lock, and isn't giving it up: > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > > > Suspending the second thread does work, but it stays inCritical. > > I'm guessing at some of this. > > > > The giant lock is no longer relevant. > > > > > > I don't see why pthreads doesn't behave the same. > > > > I'll have to read the code more. > > > > Hm. inCritical maybe shouldn't be set actually? > > I'll dig more. > > > > > > - Jay > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > > > Jay, you're the one closest to the Win32 threading code these days. > Hope you can track it down. > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I > could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild > everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll > probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe > [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 > [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 > [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 > [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe > [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 > [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 > [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 > [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 > [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 > [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 > [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c > [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 > [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf > [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within > the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is > obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it > works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers > make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references > within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > -- 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 From jay.krell at cornell.edu Thu Dec 10 13:34:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 12:34:08 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> Message-ID: I understand, but I don't understand Birrel's algorithm, though I can see we did and do implement it exactly. He stated and implemented it at a time where touching pointers didn't call into the garbage collector. The idea that just touching a pointer call into all that code is a bit hard to reason about imho...since I don't really understand all that code.. Our use of the giant lock in LockMutex/UnlockMutex appears to be in the interest of implementing a simple optimization suggested by Birrel, but one we didn't have. Ultimately I believe we remove the giant lock and emulate Java's implementation, but I don't understant it either. I can implement faithfully but I'd like to understand it. Maybe I can/should do that earlier rather than later? That moves us from not-well-understood place to another, but where the one is clearly better. - Jay > Date: Thu, 10 Dec 2009 10:18:24 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Quoting Jay K : > > > Hm. First, what changed is probably the movement of stuff from > > traced to untraced?? > > > > Which makes it more efficient and more like pthreads. > > > > I might try putting that back. > > > > What I have now though, is that in T, Mutex, and Condition, I put an > > integer field writeToBlahBlah. > > > > Every time before Lock(giant), whatever, t, m, c, I have I write to > > that field. > > > > That drastically mitigates this problem and it goes away. > > I don't really feel confident with such solutions. Maybe I'm a bit > old-fashioned, but I think that code like a threading subsystem should > be completely understood and `correct' (according to all available means). > > In my experience it is almost impossible to _test_ the `correctness' of > concurrent and concurrency implementations, as the next usage scenario or > even a simple hardware upgrade will reveal one unsafe or unprotected > critical region after the other. And reveal doesn't mean `point to' here, > but just indicate that something must be wrong somewhere ;-) > > So to keep the good spirit of Modula-3, I'd really favour a simple and > completely understandable implementation even if it has some performance > drawbacks. > > Deadlock can be completely avoided if all critical resources are known > and a well-defined locking order is heeded for each access. If there is > only one code path that may use another order, this deadlock will occur > earlier or later, preferably when there is also stress to get something > else working for a milestone or a release. > > All this should not be misinterpreted to depreciate testing; but there > can never be enough tests, and there is only a limited time to perform > them regularly. > > Olaf > > > However that still leaves me with a similar deadlock. > > > > This thread is stuck trying to suspend everyone: > > > > 0:000> ~*k > > > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > > This thread is stuck trying to get the heap lock. > > > > It is I presume "inCritical" already. > > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > > ChildEBP RetAddr > > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > > > > > > The first thread has the heap lock, and isn't giving it up: > > > > > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > > 0:000> ?? m3core!ThreadWin32__heapLock > > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > > +0x00c OwningThread : 0x00001258 > > > > > > > > > > Suspending the second thread does work, but it stays inCritical. > > > > I'm guessing at some of this. > > > > > > > > The giant lock is no longer relevant. > > > > > > > > > > > > I don't see why pthreads doesn't behave the same. > > > > > > > > I'll have to read the code more. > > > > > > > > Hm. inCritical maybe shouldn't be set actually? > > > > I'll dig more. > > > > > > > > > > > > - Jay > > > > > > > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > > From: hosking at cs.purdue.edu > > Date: Wed, 9 Dec 2009 11:13:03 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > > > > > > > Jay, you're the one closest to the Win32 threading code these days. > > Hope you can track it down. > > > > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > > > Win32. > > > > I have a wierd system..but I think the bug is real. > > In particular I was testing a small threading change on head. > > How alertable is managed, to remove its write in LockMutex, so I > > could remove the giant lock there. > > But I just had the alertable changes. > > > > > > It was hanging starting Juno. > > So I tried to test release. > > You can't use head Juno with release m3core...and I didn't rebuild > > everything. I'll do that. > > So I patched up release m3core to be binary compatible. (I'll > > probably check that in.) > > > > > > Juno still hangs. > > > > > > Here is what I see: > > > > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > > ~ is thread; * is all; k is stack. > > > > [edited] > > > > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > > ChildEBP RetAddr > > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > [c:\dev2\cm3 > > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 > > [..\src\thread\WIN32\ThreadWin32.m3 > > @ 960] > > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 > > [..\src\runtime\common\R > > TCollector.m3 @ 2253] > > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 > > [..\src\thread\WIN32\Thread > > Win32.m3 @ 111] > > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > > ... > > > > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > > ChildEBP RetAddr > > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > [c:\dev2\cm > > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 > > [..\src\thread\WIN32\ThreadWin32 > > .m3 @ 276] > > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 > > [..\src\thread\WIN32\ThreadWin > > 32.m3 @ 995] > > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 > > [..\src\runtime\common\R > > TCollector.m3 @ 716] > > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 > > [..\src\runtime\common\RTC > > ollector.m3 @ 666] > > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 > > [..\src\runtime\common\R > > TCollector.m3 @ 671] > > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 > > [..\src\runtime\common\RT > > Allocator.m3 @ 364] > > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c > > [..\src\runtime\common\R > > TAllocator.m3 @ 222] > > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 > > [..\src\runtime\common\ > > RTAllocator.m3 @ 120] > > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf > > [..\src\JunoCompile.m3 > > @ 987] > > ... > > > > > > Let's look at two of our important locks: > > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > > > > 0:006> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 2 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000b0 > > +0x010 LockSemaphore : 0x00000708 > > +0x014 SpinCount : 0 > > > > > > 0:006> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000b34 > > +0x010 LockSemaphore : 0x000006ec > > +0x014 SpinCount : 0 > > > > > > So you can see there is a circularity and deadlock. > > Thread 6 owns giant lock and is waiting for heap lock. > > Thread 7 owns heap lock and is waiting for giant lock. > > > > > > This occurs because Win32 LockMutex uses traced references within > > the giant lock. ? > > Use of traced references implies a possible need to take the heap lock. > > Doing darn near anything implies a need to use the giant lock. > > > > > > Any ideas Tony? > > > > > > I'm not crazy or have a messed up tree, right? > > I mean, now that I've discussed it, the deadlock potential is > > obviously there, right? > > > > > > Pthreads is safe of course, no giant lock. > > > > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > > That should help? > > The giant lock would still remain though. > > > > > > Now, we know that condition variables are implementable well enough on Win32. > > Either with a giant lock, or how Java does it. > > Aside: I don't fully understand the Java implementation, but if it > > works, it is goodness. > > It has no giant lock. I don't understand how the sequence numbers > > make it work. > > > > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > > that it works at ll..doesn't interact well with traced references > > within its own implementation? > > Maybe this stuff can be teased apart? > > > > > > Same thing with a coherent (I think) release build: > > > > 0:008> ~*k > > > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > > > ... > > > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > > ChildEBP RetAddr > > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > > > > 0:008> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 5 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000d0 > > +0x010 LockSemaphore : 0x00000700 > > +0x014 SpinCount : 0 > > > > > > 0:008> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000080 > > +0x010 LockSemaphore : 0x000006fc > > +0x014 SpinCount : 0 > > > > > > 80 has the heap lock and is trying to get the giant lock > > D0 has the giant lock and is trying to get the heap lock > > Because of the use of traced references in LockMutex. > > > > > > - Jay > > > > > > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 10 17:10:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 11:10:58 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> The second thread should *not* be inCritical when trying to LockHeap. Are you sure that is the case? As it stands you need to be able to suspend a thread even if it is waiting on the heap lock (i.e., because the collector thread already holds the lock). On 10 Dec 2009, at 01:59, Jay K wrote: > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > From hosking at cs.purdue.edu Thu Dec 10 17:12:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 11:12:45 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, Message-ID: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 17:12:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 16:12:58 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> , <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> Message-ID: I was wrong on that point. Upon debugging it I found the stack pointer was deemed bad, because I had context* vs. context** wrong. That we even check the stack pointer is dubious but it is the historical behavior -- I merely made the code to do it far more direct/faster/reliable. - Jay > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:10:58 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > The second thread should *not* be inCritical when trying to LockHeap. Are you sure that is the case? As it stands you need to be able to suspend a thread even if it is waiting on the heap lock (i.e., because the collector thread already holds the lock). > > On 10 Dec 2009, at 01:59, Jay K wrote: > > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > > Which makes it more efficient and more like pthreads. > > I might try putting that back. > > > > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > > That drastically mitigates this problem and it goes away. > > > > > > However that still leaves me with a similar deadlock. > > > > > > This thread is stuck trying to suspend everyone: > > > > 0:000> ~*k > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > > > > This thread is stuck trying to get the heap lock. > > It is I presume "inCritical" already. > > > > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > > ChildEBP RetAddr > > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > > The first thread has the heap lock, and isn't giving it up: > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > > 0:000> ?? m3core!ThreadWin32__heapLock > > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > > +0x00c OwningThread : 0x00001258 > > > > > > Suspending the second thread does work, but it stays inCritical. > > I'm guessing at some of this. > > > > The giant lock is no longer relevant. > > > > > > I don't see why pthreads doesn't behave the same. > > > > I'll have to read the code more. > > > > Hm. inCritical maybe shouldn't be set actually? > > I'll dig more. > > > > > > - Jay > > > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > > From: hosking at cs.purdue.edu > > Date: Wed, 9 Dec 2009 11:13:03 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > > > Win32. > > > > I have a wierd system..but I think the bug is real. > > In particular I was testing a small threading change on head. > > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > > But I just had the alertable changes. > > > > > > It was hanging starting Juno. > > So I tried to test release. > > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > > > > Juno still hangs. > > > > > > Here is what I see: > > > > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > > ~ is thread; * is all; k is stack. > > > > [edited] > > > > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > > ChildEBP RetAddr > > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > > @ 960] > > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > > TCollector.m3 @ 2253] > > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > > Win32.m3 @ 111] > > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > > ... > > > > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > > ChildEBP RetAddr > > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > > .m3 @ 276] > > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > > 32.m3 @ 995] > > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > > TCollector.m3 @ 716] > > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > > ollector.m3 @ 666] > > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > > TCollector.m3 @ 671] > > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > > Allocator.m3 @ 364] > > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > > TAllocator.m3 @ 222] > > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > > RTAllocator.m3 @ 120] > > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > > @ 987] > > ... > > > > > > Let's look at two of our important locks: > > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > > > > 0:006> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 2 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000b0 > > +0x010 LockSemaphore : 0x00000708 > > +0x014 SpinCount : 0 > > > > > > 0:006> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000b34 > > +0x010 LockSemaphore : 0x000006ec > > +0x014 SpinCount : 0 > > > > > > So you can see there is a circularity and deadlock. > > Thread 6 owns giant lock and is waiting for heap lock. > > Thread 7 owns heap lock and is waiting for giant lock. > > > > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > > Use of traced references implies a possible need to take the heap lock. > > Doing darn near anything implies a need to use the giant lock. > > > > > > Any ideas Tony? > > > > > > I'm not crazy or have a messed up tree, right? > > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > > > > Pthreads is safe of course, no giant lock. > > > > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > > That should help? > > The giant lock would still remain though. > > > > > > Now, we know that condition variables are implementable well enough on Win32. > > Either with a giant lock, or how Java does it. > > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > > It has no giant lock. I don't understand how the sequence numbers make it work. > > > > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > > that it works at ll..doesn't interact well with traced references within its own implementation? > > Maybe this stuff can be teased apart? > > > > > > Same thing with a coherent (I think) release build: > > > > 0:008> ~*k > > > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > > > ... > > > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > > ChildEBP RetAddr > > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > > > > 0:008> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 5 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000d0 > > +0x010 LockSemaphore : 0x00000700 > > +0x014 SpinCount : 0 > > > > > > 0:008> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000080 > > +0x010 LockSemaphore : 0x000006fc > > +0x014 SpinCount : 0 > > > > > > 80 has the heap lock and is trying to get the giant lock > > D0 has the giant lock and is trying to get the heap lock > > Because of the use of traced references in LockMutex. > > > > > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 17:44:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 16:44:12 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: ok. LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. BroadcastHeap just sets a boolean that is looked at by UnlockHeap. Not my doing, but I just moved it from head to release. LockMutex I changed to just EnterCriticalSection. My doing. BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, then BroadcastHeap would have to call Broadcast and take the giant lock. I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. - Jay From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 10 18:32:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 12:32:36 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> I thought you were saying you had a problem with access to traced state... On 10 Dec 2009, at 11:44, Jay K wrote: > ok. > > LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. > BroadcastHeap just sets a boolean that is looked at by UnlockHeap. > Not my doing, but I just moved it from head to release. > LockMutex I changed to just EnterCriticalSection. > My doing. > > > BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. > That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, > then BroadcastHeap would have to call Broadcast and take the giant lock. > > > I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:12:45 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. > > On 10 Dec 2009, at 02:43, Jay K wrote: > > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 18:33:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 17:33:42 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> , <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> Message-ID: I did. I was. I think it is ok now. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 12:32:36 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I thought you were saying you had a problem with access to traced state... On 10 Dec 2009, at 11:44, Jay K wrote: ok. LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. BroadcastHeap just sets a boolean that is looked at by UnlockHeap. Not my doing, but I just moved it from head to release. LockMutex I changed to just EnterCriticalSection. My doing. BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, then BroadcastHeap would have to call Broadcast and take the giant lock. I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. - Jay From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:22:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:22:48 +0000 Subject: [M3devel] "port simple race condition fix from head related to stopping a thread before/after it has any traced references" In-Reply-To: <20091211111426.0EA142474001@birch.elegosoft.com> References: <20091211111426.0EA142474001@birch.elegosoft.com> Message-ID: Something is fishy here. The change is fine, but there could only be a problem if suspending the thread didn't work? You know, the stack value shouldn't be changing? I'm pretty sure I saw this be a problem on some configuration, but maybe it was only user threads and maybe they are relevantly different? Also Tony is it ok to RTHeapRep.FlushThreadState unconditionally here? - Jay > Date: Fri, 11 Dec 2009 12:14:26 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 12:14:26 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > release_branch_cm3_5_8 > ThreadPThreadC.c > > Log message: > port simple race condition fix from head related to stopping a thread before/after it has any traced references > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:35:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:35:02 +0000 Subject: [M3devel] slight differences in m3core release vs. head? Message-ID: Tony, which versions do you prefer in which branch? C:\dev2\cm3.release_branch_cm3_5_8\m3-libs\m3core\src\runtime\common>diff -u C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3 RTHeapStats.m3 --- C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3 2009-12- 10 09:04:05.546875000 -0800 +++ RTHeapStats.m3 2009-12-11 02:51:53.468750000 -0800 @@ -330,7 +330,7 @@ VAR fp: UNTRACED REF ADDRESS := start; BEGIN (* scan the stack or registers *) - WHILE fp < stop DO + WHILE fp <= stop DO WITH page = RTHeapRep.AddressToPage(fp^), d = page.desc DO IF page # NIL AND d.space = RTHeapRep.Space.Current THEN VisitPage(page); C:\dev2\cm3.release_branch_cm3_5_8\m3-libs\m3core\src\runtime\common>diff -u C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3 RTCollector.m3 --- C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3 2009-12- 11 02:50:02.234375000 -0800 +++ RTCollector.m3 2009-12-11 02:51:44.781250000 -0800 @@ -519,7 +519,9 @@ PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN - IF NOT (start < stop) THEN RETURN END; + IF start = NIL AND stop = NIL THEN + RETURN; + END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO @@ -2210,7 +2212,7 @@ END; END WeakCleaner; There are also a bunch of user thread diffs I haven't looked at closely. And a bunch of diffs I understand. I think off by one thing in NoteStackLocations is subtle. The ranges come from code that might not be so precise or might be themselves off by one. I believe in Win32 I pass in for stop the "just past the end" value. In which case you want "<". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:44:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:44:27 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: Btw, I don't understand how all the barriers work so seemingly lock free. Or maybe they do often take locks? That is why I don't trust arbitrary invocations of barriers, since I don't know how long the results stay valid. I really just need to read and internalize this barrier stuff. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 13:08:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 12:08:27 +0000 Subject: [M3devel] "start, limit" vs. "start, stop" In-Reply-To: <20091211120558.37E0F2474001@birch.elegosoft.com> References: <20091211120558.37E0F2474001@birch.elegosoft.com> Message-ID: > note that there are still "start, stop" pairs, in addition to the > "start, limit" pairs There are still some "start, stop", but they are consistent, things compile. C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3(519):PROCEDURE NoteStackLocations (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(297):PROCEDURE GetThread (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(329):PROCEDURE ScanPages (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(353):PROCEDURE ScanThreadRoots (start, stop: ADDRESS; on_stack: BOOLEAN) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(383):PROCEDURE ScanThreadPageRoots (start, stop: ADDRESS; on_stack: BOOLEAN) = C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3(976):PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) = C:\dev2\cm3.2\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3(808):PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) = I think the names are in the type, like for calling with named parameters, but the functions don't actually have to match. The perfectionist in me says they should all be consistent though. The pragmatist says basically no change is worthwhile here, even the ones already made. - Jay > Date: Fri, 11 Dec 2009 13:05:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 13:05:58 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: Tag: > release_branch_cm3_5_8 > RTThread.i3 > cm3/m3-libs/m3core/src/thread/POSIX/: Tag: > release_branch_cm3_5_8 > ThreadPosix.i3 > ThreadPosix.m3 > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > release_branch_cm3_5_8 > ThreadPThread.m3 > cm3/m3-libs/m3core/src/thread/WIN32/: Tag: > release_branch_cm3_5_8 > ThreadWin32.m3 > > Log message: > port from head: rename parameter in function pointer type from "stop" > to "limit" > note that there are still "start, stop" pairs, in addition to the > "start, limit" pairs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 14:55:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 08:55:26 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: Soon we will make the barriers lock free. Right now they lock the heap (blurgh). But we will still need them to be inCritical to prevent GC occurring in the middle of a barrier. On 11 Dec 2009, at 06:44, Jay K wrote: > Btw, I don't understand how all the barriers work so seemingly lock free. > Or maybe they do often take locks? > That is why I don't trust arbitrary invocations of barriers, since I don't know how long > the results stay valid. I really just need to read and internalize this barrier stuff. > > > - Jay > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:12:45 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. > > On 10 Dec 2009, at 02:43, Jay K wrote: > > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:05:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Message-ID: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:09:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:09:37 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:17:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:17:16 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:41:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:41:53 +0000 Subject: [M3devel] FW: some open bugs In-Reply-To: <4B1C34ED.1E75.00D7.1@scires.com> References: , , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com>, , <4B1C34ED.1E75.00D7.1@scires.com> Message-ID: Sorry no not at this time. I haven't looked in a bit and it stumped me at the time. I think we should either have a build per C runtime version or /maybe/ link to libmt.lib. - Jay >> Can you be more specific about the nature of the "windows C runtime version issue" you report below ? Regards, Randy >>> Jay K 12/6/2009 4:00 AM >>> > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 15:57:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 09:57:13 -0500 Subject: [M3devel] "port simple race condition fix from head related to stopping a thread before/after it has any traced references" In-Reply-To: References: <20091211111426.0EA142474001@birch.elegosoft.com> Message-ID: <45DB4B67-5013-4A8D-BDEB-8EFE9B08C1F2@cs.purdue.edu> On 11 Dec 2009, at 06:22, Jay K wrote: > Something is fishy here. The change is fine, but there could only be a problem > if suspending the thread didn't work? You know, the stack value shouldn't > be changing? I'm pretty sure I saw this be a problem on some configuration, > but maybe it was only user threads and maybe they are relevantly different? > > Also Tony is it ok to RTHeapRep.FlushThreadState unconditionally here? I think so: only stopped threads have this done to them. If they are using the thread state (for allocation) then they are inCritical. > > - Jay > > > Date: Fri, 11 Dec 2009 12:14:26 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/11 12:14:26 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > > release_branch_cm3_5_8 > > ThreadPThreadC.c > > > > Log message: > > port simple race condition fix from head related to stopping a thread before/after it has any traced references > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:02:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:02:16 +0000 Subject: [M3devel] Why do we not check stackbase=NIL anymore in ProcessOther? In-Reply-To: <20091211145750.8D48E2474001@birch.elegosoft.com> References: <20091211145750.8D48E2474001@birch.elegosoft.com> Message-ID: I know what I was thinking, but it doesn't make sense any more. I could have sworn I saw a race where the value changed between the check and the subsequent read/use. That makes sense, in that I don't change the value under a lock. But it doesn't make sense, in that the changer should be suspended. The check is done shortly after in the C code though. There is just one read, and the purported race is gone. It should be ok. The one uncertainty on my part is what the HeapRep.FlushState does. I looked at, but I didn't follow through as to the other uses of the state it changes. - Jay > Date: Fri, 11 Dec 2009 15:57:50 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 09/12/11 15:57:50 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Tidy a little. > Why do we not check stackbase=NIL anymore in ProcessOther? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 16:06:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 10:06:03 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: > Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? > > > I'm not sure this is going to work out, but: > I'm "rewriting" stuff to use a separate event for alerting. > alertable goes away > There will be two events: > waitEvent, for condition variables > alertEvent, for alerting > > > roughly speaking: > > > AlertPause: WaitForSingleObject(alertEvent) > AlertWait: > alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) > Alert(t): SetEvent(t.alertEvent); > TestAlert: alerted := WaitForSingleObject(alertEvent, 0); > > > It seems simple enough. > That shows all the ingredients. > That'll eliminate a lot of the global locking. > And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. > You can't just use the Java code because it doesn't include alertability. > You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. > The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:07:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:07:23 +0000 Subject: [M3devel] RTOS.Crash In-Reply-To: <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> References: <20091211114257.4EA062474001@birch.elegosoft.com>, <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> Message-ID: > We should do the same for POSIX too I think. Posix just calls abort. Posix: PROCEDURE Crash () = BEGIN Cstdlib.abort (); LOOP END; (* wait *) END Crash; Win32: PROCEDURE Crash () = CONST Magic = 1 * ADRSIZE (INTEGER); (* == offset of "fp" in this frame *) VAR fp: ADDRESS := ADR (fp) + Magic; (* == my frame pointer *) BEGIN IF WinBase.IsDebuggerPresent () # 0 THEN (* I moved these three lines up. *) WinBase.DebugBreak (); END; RTThread.SuspendOthers (); RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); RTSignal.RestoreHandlers (); (* so we really do crash... *) Exit (-1); END Crash; That said..I'm missing something and I should review the code. Obviously there are calls elsewhere to DumpStack, and they or may not be similarly crufty. /Actually/ one thing I'd like is for the m3core to be able to dump better callstacks. Like, the ability to carry more debuginfo of its own custom format in itself. Like, to get line numbers. - Jay From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:00:35 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 We should do the same for POSIX too I think. On 11 Dec 2009, at 12:42, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/12/11 12:42:57 Modified files: cm3/m3-libs/m3core/src/runtime/WIN32/: Tag: release_branch_cm3_5_8 RTOS.m3 Log message: port from head: very small change that makes debugging sometimes much better (break right into debugger, don't waste time trying to suspend threads and dump stacks, the debugger does a much better job of suspending threads and usually (if you have symbols) of dumping stacks) If you aren't using a debugger, then no change. The thing about RestoreHandlers can probably just be removed since in my brief experience the DebugBreak works fine before it. Really it can probably just go like this: If debugger debugbreak ELSE suspend others, maybe dumpstack one of the important parts restore handlers probably can be removed Exit(-1) also important though maybe should be TerminateProcess which is much quicker/cleaner doesn't run all the dllmains though currently I just made the small change of moving the debugbreak much earlier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:09:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:09:20 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> References: , <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Message-ID: No. I answered my question -- it is in case of really long pauses -- over 4billion milliseconds. The waits are broken up into chunks of that size. We use a 53bit? mantissa longreal to represent seconds whereas Win32 wait is 32bit number of milliseconds. The one doesn't fit in the other. - Jay Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:06:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 16:10:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 10:10:10 -0500 Subject: [M3devel] RTOS.Crash In-Reply-To: References: <20091211114257.4EA062474001@birch.elegosoft.com>, <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> Message-ID: <09E070FF-B13F-405F-A6E9-6F73AEEFE680@cs.purdue.edu> OK, cool. On 11 Dec 2009, at 10:07, Jay K wrote: > > We should do the same for POSIX too I think. > > Posix just calls abort. > > Posix: > PROCEDURE Crash () = > BEGIN > Cstdlib.abort (); > LOOP END; (* wait *) > END Crash; > > > Win32: > > > PROCEDURE Crash () = > CONST Magic = 1 * ADRSIZE (INTEGER); (* == offset of "fp" in this frame *) > VAR fp: ADDRESS := ADR (fp) + Magic; (* == my frame pointer *) > BEGIN > IF WinBase.IsDebuggerPresent () # 0 THEN (* I moved these three lines up. *) > WinBase.DebugBreak (); > END; > RTThread.SuspendOthers (); > RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); > RTSignal.RestoreHandlers (); (* so we really do crash... *) > Exit (-1); > END Crash; > > > That said..I'm missing something and I should review the code. > Obviously there are calls elsewhere to DumpStack, and they or may not be similarly crufty. > > > /Actually/ one thing I'd like is for the m3core to be able to dump better callstacks. > Like, the ability to carry more debuginfo of its own custom format in itself. > Like, to get line numbers. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 11 Dec 2009 10:00:35 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > We should do the same for POSIX too I think. > > On 11 Dec 2009, at 12:42, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 12:42:57 > > Modified files: > cm3/m3-libs/m3core/src/runtime/WIN32/: Tag: > release_branch_cm3_5_8 > RTOS.m3 > > Log message: > port from head: very small change that makes debugging sometimes much better > (break right into debugger, don't waste time trying to suspend threads > and dump stacks, the debugger does a much better job of suspending > threads and usually (if you have symbols) of dumping stacks) > If you aren't using a debugger, then no change. > > The thing about RestoreHandlers can probably just be removed since > in my brief experience the DebugBreak works fine before it. > > Really it can probably just go like this: > If debugger > debugbreak > ELSE > suspend others, maybe > dumpstack one of the important parts > restore handlers probably can be removed > Exit(-1) also important though maybe should be TerminateProcess which is much quicker/cleaner > doesn't run all the dllmains > > though currently I just made the small change of moving the debugbreak much earlier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:09:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:09:44 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> References: , <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Message-ID: ps: not to mention the exponent! From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 AlertPause polls instead of one big wait? Date: Fri, 11 Dec 2009 15:09:20 +0000 No. I answered my question -- it is in case of really long pauses -- over 4billion milliseconds. The waits are broken up into chunks of that size. We use a 53bit? mantissa longreal to represent seconds whereas Win32 wait is 32bit number of milliseconds. The one doesn't fit in the other. - Jay Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:06:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 19:12:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 13:12:00 -0500 Subject: [M3devel] Why do we not check stackbase=NIL anymore in ProcessOther? In-Reply-To: References: <20091211145750.8D48E2474001@birch.elegosoft.com> Message-ID: <1884D92B-9409-4AD5-966B-D3E566B7784E@cs.purdue.edu> On 11 Dec 2009, at 10:02, Jay K wrote: > I know what I was thinking, but it doesn't make sense any more. > I could have sworn I saw a race where the value changed between > the check and the subsequent read/use. > That makes sense, in that I don't change the value under a lock. > But it doesn't make sense, in that the changer should be suspended. > The check is done shortly after in the C code though. > There is just one read, and the purported race is gone. > It should be ok. The one uncertainty on my part is what the HeapRep.FlushState does. > I looked at, but I didn't follow through as to the other uses of the state it changes. Ah, yes, I see the test now in the C code. Doesn't make any sense that doing it there should make any difference though. As for the flushing of the heap state, all that is doing is relinquishing the thread's heap allocation context so that GC can occur. > > > - Jay > > > > Date: Fri, 11 Dec 2009 15:57:50 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/12/11 15:57:50 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > > > Log message: > > Tidy a little. > > Why do we not check stackbase=NIL anymore in ProcessOther? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sat Dec 12 05:50:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 11 Dec 2009 23:50:57 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: <4B22D975.1E75.00D7.1@scires.com> Jay, I notice you say something about Win9x below. I never had much success with Win9x back in the cm3 v4.1 days. Farshad and company stated that they would only support WindowsNT4.0 back then. I think it would be fine at this point to just support the newer stuff (Windows NT4.0 / 2000 / XP / Vista / Windows 7) and not worry about the old 9x versions or even NT3.5. I've been watching all the activity on threading and mutexes. I keep updating from the HEAD branch and rebuilding on XP and Vista to make sure stuff still compiles. I must admit all these low-level changes concern me for the same reasons Olaf outlined a few days ago. I've not had much time to devote to cm3 lately, but I will try to test using some of my multi-threaded programs as soon as I can. However, I fear it will be hard to tell if something is only "slightly broken" or "slightly misbehaves" because unless you see a crash or obvious behavior flaw, you won't know it is "slightly" broken. I did contribute a "Mutex Checker" test program a few weeks back. I'll keep running it, but it doesn't test all the alert and condition variable stuff. I think we need some test programs that can prove correctness, but these are going to be hard to develop I fear. Regards, Randy >>> Jay K 12/11/2009 9:17 AM >>> [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 06:37:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 05:37:44 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <4B22D975.1E75.00D7.1@scires.com> References: , , <4B22D975.1E75.00D7.1@scires.com> Message-ID: Randy, I was just going to ask about this..: building with Visual C++ 2.0 (banner says copyright 1994): Time.mo : error LNK2001: unresolved external symbol "_GetSystemTimeAsFileTime at 4" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_GetIcon at 12" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_LoadImageA at 28" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_Remove at 8" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_ReplaceIcon at 12" ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange" ThreadWin32.mo : error LNK2001: unresolved external symbol "_InterlockedCompareExchange at 12" RTOS.mo : error LNK2001: unresolved external symbol "_IsDebuggerPresent at 0" m3core.dll : error LNK1120: 8 unresolved externals building with Visual C++ 4.0 (circa 1996?): ThreadWin32.mo : error LNK2001: unresolved external symbol _InterlockedCompareExchange at 12 ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange m3core.dll : fatal error LNK1120: 2 unresolved externals building with Visual C++ 4.2 (circa 1996?): works Which is also some significant measure of what operating systems work. I had deleted \cm3\lib. If you build in m3-win\import-libs, then the problems drop to just InterlockedCompareExchange, and that is easily fixed. Though again it is a measure of what operating system versions will work. I'm really undecided here. Our dependency on anything beyond Windows 95/NT 3.1, maybe even Win32s, is really slight or nonexistant. If you look at the above list for example, InterlockedCompareExchange I /just/ introduced to replace a lock, a lock that I had only introduced recently as part of removing the giant lock (the lock is much smaller). IsDebuggerPresent is really optional. GetSystemTimeAsFileTime is trivial to do without. ImageList stuff probably isn't needed -- we certainly get stuff at the wrong layer because of a certain part of our architecture. You know, normally in C / C++, there's no comctl32.dll support at any lower level, whoever needs it just #includes commctl.h. It is our "wrappers" that introduce this dependency. The way I discover the stack boundaries might not work on Win9x/Win32s, but it might. For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007. If all that works, things are better than they were for a long time. For many months Juno would sometimes hang due to a bug that affected all programs. Granted, we didn't necessarily ever release that bug. In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD. For better and for worse, these parts of the system do need work imho. My changes are also mostly for the simpler. Of course nobody can decide what is "simple". The change to remove the giant lock from LockMutex/UnlockMutex agrees with Birrel's paper, which only implies the lock might be there for an optimization elsewhere, an optimization that we didn't have. Let me know of any slight or suspected problem and esp. let me run the code. We should be ok, or better. :) For the alert thing we could do a version check and/or GetProcAddress on QueueUserAPC, or actually I suspect it is easy to be Win9x compatible. You'd have each thread open/create its own anonymous pipe and to alert the thread you'd just write a byte the pipe. I could test older systems in VMs. I mostly just use XP. - Jay Date: Fri, 11 Dec 2009 23:50:57 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? Jay, I notice you say something about Win9x below. I never had much success with Win9x back in the cm3 v4.1 days. Farshad and company stated that they would only support WindowsNT4.0 back then. I think it would be fine at this point to just support the newer stuff (Windows NT4.0 / 2000 / XP / Vista / Windows 7) and not worry about the old 9x versions or even NT3.5. I've been watching all the activity on threading and mutexes. I keep updating from the HEAD branch and rebuilding on XP and Vista to make sure stuff still compiles. I must admit all these low-level changes concern me for the same reasons Olaf outlined a few days ago. I've not had much time to devote to cm3 lately, but I will try to test using some of my multi-threaded programs as soon as I can. However, I fear it will be hard to tell if something is only "slightly broken" or "slightly misbehaves" because unless you see a crash or obvious behavior flaw, you won't know it is "slightly" broken. I did contribute a "Mutex Checker" test program a few weeks back. I'll keep running it, but it doesn't test all the alert and condition variable stuff. I think we need some test programs that can prove correctness, but these are going to be hard to develop I fear. Regards, Randy >>> Jay K 12/11/2009 9:17 AM >>> [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 12 06:59:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Dec 2009 00:59:03 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: , , <4B22D975.1E75.00D7.1@scires.com> Message-ID: FreeBSD pthreads has not previously been supported. Just Linux, Solaris, OSX. On 12 Dec 2009, at 00:37, Jay K wrote: > > Randy, I was just going to ask about this..: > > > > > > building with Visual C++ 2.0 (banner says copyright 1994): > > Time.mo : error LNK2001: unresolved external symbol "_GetSystemTimeAsFileTime at 4" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_GetIcon at 12" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_LoadImageA at 28" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_Remove at 8" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_ReplaceIcon at 12" > ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange" > ThreadWin32.mo : error LNK2001: unresolved external symbol "_InterlockedCompareExchange at 12" > RTOS.mo : error LNK2001: unresolved external symbol "_IsDebuggerPresent at 0" > m3core.dll : error LNK1120: 8 unresolved externals > > > > building with Visual C++ 4.0 (circa 1996?): > ThreadWin32.mo : error LNK2001: unresolved external symbol _InterlockedCompareExchange at 12 > ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange > m3core.dll : fatal error LNK1120: 2 unresolved externals > > > > building with Visual C++ 4.2 (circa 1996?): > works > > > > Which is also some significant measure of what operating systems work. > > I had deleted \cm3\lib. If you build in m3-win\import-libs, then the problems drop to just InterlockedCompareExchange, and that is easily fixed. Though again it is a measure of what operating system versions will work. > > > > > > I'm really undecided here. Our dependency on anything beyond Windows 95/NT 3.1, maybe even Win32s, is really slight or nonexistant. If you look at the above list for example, InterlockedCompareExchange I /just/ introduced to replace a lock, a lock that I had only introduced recently as part of removing the giant lock (the lock is much smaller). IsDebuggerPresent is really optional. GetSystemTimeAsFileTime is trivial to do without. ImageList stuff probably isn't needed -- we certainly get stuff at the wrong layer because of a certain part of our architecture. You know, normally in C / C++, there's no comctl32.dll support at any lower level, whoever needs it just #includes commctl.h. It is our "wrappers" that introduce this dependency. > > The way I discover the stack boundaries might not work on Win9x/Win32s, but it might. > > > > > > For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007. > > If all that works, things are better than they were for a long time. > > For many months Juno would sometimes hang due to a bug that affected all programs. > > Granted, we didn't necessarily ever release that bug. > > In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD. > > For better and for worse, these parts of the system do need work imho. > > > > > > My changes are also mostly for the simpler. Of course nobody can decide what is "simple". > > The change to remove the giant lock from LockMutex/UnlockMutex agrees with Birrel's paper, which only implies the lock might be there for an optimization elsewhere, an optimization that we didn't have. > > Let me know of any slight or suspected problem and esp. let me run the code -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 07:47:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 06:47:28 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? Message-ID: cloning headers vs. indirection/win32 So..I've been a champion of pushing code into C to avoid cloning headers. I'm not sure the following statement is logical: It is easier to clone "windows.h" than "libc.h". The possible logic is that there is less variation. There is very little #ifdef in windows.h, whereas "libc.h" contains both #ifdefs and there are to some extent n different versions. Another possible explanation is that windows.h was cloned long ago not by me and "libc.h" I've had to deal with more, on "new" systems. It is an exaggeration to say OpenBSD/NetBSD/FreeBSD/Linux/Solaris/Darwin etc. are "completely" different independent rewrites but it is also an exaggeration to say they are "the same". It is tempting to say the stat struct is the only problem, but it isn't. If it IS logical, then some of this could/should be undone for Windows. In particular I'm pretty sympathetic to having the Modula-3 code use Initialize/Enter/LeaveCriticalSection directly. With the following caveats: - maybe it isn't logical - as things are currently, there is more opportunity to merge pthreads and Win32 implementation Going "back" to a somewhat more optimized Win32 implementation is a bit of a barrier to merging them. I'll probably things asis in this regard. You know..to be "consistent", I should go through ThreadWin32.m3's: FROM WinNT IMPORT LONG, HANDLE, DWORD, UINT32; FROM WinBase IMPORT WaitForSingleObject, INFINITE, CloseHandle, CreateThread, ResumeThread, Sleep, SuspendThread, GetThreadContext, SetLastError, GetLastError, CREATE_SUSPENDED, GetCurrentThreadId, InterlockedCompareExchange, InterlockedExchange, InterlockedIncrement, InterlockedDecrement, SetEvent, WAIT_OBJECT_0, CreateEvent, WaitForMultipleObjects; FROM ThreadContext IMPORT PCONTEXT; and reduce those and/or wrap them in C like is done for m3core/unix. Well, maybe. Constants are easy, plus statically link a la hand.obj/Uconstants.obj. Functions are easy. "base" types like LONG, HANDLE, DWORD, UINT32 we just go ahead and clone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 08:27:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 07:27:33 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? In-Reply-To: References: Message-ID: Actually it appears the indirection is needed for CRITICAL_SECTION. WinNT.i3: (* NOTE: "PRTL_CRITICAL_SECTION" is declared as a Modula-3 opaque type and then immediately revealed so that "EnterCriticalSection()" and "LeaveCriticalSection()" won't require checks by the GC wrapper routines. Clearly, if a Windows critical section is inside an M3 traced ref (which moves!) the system is going to crash. Hence, the extra GC check isn't needed. *) TYPE PRTL_CRITICAL_SECTION <: ADDRESS; REVEAL PRTL_CRITICAL_SECTION = UNTRACED BRANDED "WinNT.PRTL_CRITICAL_SECTION" REF RTL_CRITICAL_SECTION; But we could still have the global locks (slotLock, activeLock, initLock, perfLock etc.) be "direct" CRITICAL_SECTIONS and just the "dynamic" ones (Thread.Mutex) have the indirection. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sat, 12 Dec 2009 06:47:28 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? cloning headers vs. indirection/win32 So..I've been a champion of pushing code into C to avoid cloning headers. I'm not sure the following statement is logical: It is easier to clone "windows.h" than "libc.h". The possible logic is that there is less variation. There is very little #ifdef in windows.h, whereas "libc.h" contains both #ifdefs and there are to some extent n different versions. Another possible explanation is that windows.h was cloned long ago not by me and "libc.h" I've had to deal with more, on "new" systems. It is an exaggeration to say OpenBSD/NetBSD/FreeBSD/Linux/Solaris/Darwin etc. are "completely" different independent rewrites but it is also an exaggeration to say they are "the same". It is tempting to say the stat struct is the only problem, but it isn't. If it IS logical, then some of this could/should be undone for Windows. In particular I'm pretty sympathetic to having the Modula-3 code use Initialize/Enter/LeaveCriticalSection directly. With the following caveats: - maybe it isn't logical - as things are currently, there is more opportunity to merge pthreads and Win32 implementation Going "back" to a somewhat more optimized Win32 implementation is a bit of a barrier to merging them. I'll probably things asis in this regard. You know..to be "consistent", I should go through ThreadWin32.m3's: FROM WinNT IMPORT LONG, HANDLE, DWORD, UINT32; FROM WinBase IMPORT WaitForSingleObject, INFINITE, CloseHandle, CreateThread, ResumeThread, Sleep, SuspendThread, GetThreadContext, SetLastError, GetLastError, CREATE_SUSPENDED, GetCurrentThreadId, InterlockedCompareExchange, InterlockedExchange, InterlockedIncrement, InterlockedDecrement, SetEvent, WAIT_OBJECT_0, CreateEvent, WaitForMultipleObjects; FROM ThreadContext IMPORT PCONTEXT; and reduce those and/or wrap them in C like is done for m3core/unix. Well, maybe. Constants are easy, plus statically link a la hand.obj/Uconstants.obj. Functions are easy. "base" types like LONG, HANDLE, DWORD, UINT32 we just go ahead and clone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 16:25:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 15:25:44 +0000 Subject: [M3devel] to share code between Join and AlertJoin or not? Message-ID: Here's a case where it is not clear if the code is worth sharing: Join and AlertJoin share XJoin: PROCEDURE XJoin (t: T; alertable: BOOLEAN): REFANY RAISES {Alerted} = VAR (* The order of the handles is important. *) handles := ARRAY [0..1] OF HANDLE {t.act.handle, NIL(*alertEvent*)}; wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; IF alertable THEN handles[1] := GetActivation().alertEvent; END; wait := WaitForMultipleObjects(1 + ORD(alertable), ADR(handles[0]), 0, INFINITE); <* ASSERT wait # WAIT_TIMEOUT *> <* ASSERT wait = WAIT_OBJECT_0 OR wait = (WAIT_OBJECT_0 + 1) *> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT wait = WAIT_OBJECT_0 + 1 *> <* ASSERT alertable *> RAISE Alerted; END; END XJoin; PROCEDURE Join(t: T): REFANY = <*FATAL Alerted*> BEGIN IF DEBUG THEN ThreadDebug.Join(t); END; RETURN XJoin(t, alertable := FALSE); END Join; PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} = BEGIN IF DEBUG THEN ThreadDebug.AlertJoin(t); END; RETURN XJoin(t, alertable := TRUE); END AlertJoin; OR without code sharing, it'd go like: PROCEDURE Join(t: T): REFANY = VAR wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForSingleObject(t.act.handle, INFINITE); <* ASSERT wait = WAIT_OBJECT_0 *> t.joined := 1; RETURN t.result; END Join; PROCEDURE AlertJoin (t: T): REFANY RAISES {Alerted} = VAR (* The order of the handles is important. *) handles := ARRAY [0..1] OF HANDLE {t.act.handle, GetActivation().alertEvent}; wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForMultipleObjects(2, ADR(handles[0]), 0, INFINITE); <* ASSERT wait # WAIT_TIMEOUT *> <* ASSERT wait = WAIT_OBJECT_0 OR wait = (WAIT_OBJECT_0 + 1) *> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT wait = WAIT_OBJECT_0 + 1 *> RAISE Alerted; END; END AlertJoin; anyone have strong feelings either way? If we used win32 alertable waits, then the case for code sharing would be stronger, it'd go like: PROCEDURE XJoin (t: T; alertable: BOOLEAN): REFANY RAISES {Alerted} = VAR wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForSingleObjectEx(t.act.handle, INFINITE, ORD(alertable)); <* ASSERT wait = WAIT_OBJECT_0 OR wait = WAIT_IO_COMPLETION*> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT alertable *> RAISE Alerted; END; END XJoin; - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 01:37:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 00:37:43 +0000 Subject: [M3devel] AlertPause(0) is alertable? Message-ID: If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 04:41:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091213033734.E108E2474002@birch.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> Message-ID: 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 04:46:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 03:46:57 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 05:56:08 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 12 Dec 2009 23:56:08 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: Message-ID: <4B242C23.1E75.00D7.1@scires.com> My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 05:56:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 04:56:18 +0000 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: <4B242C23.1E75.00D7.1@scires.com> References: , <4B242C23.1E75.00D7.1@scires.com> Message-ID: Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:02:34 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:02:34 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com> Message-ID: <4B242DA5.1E75.00D7.1@scires.com> Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:04:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:04:43 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242DA5.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com> Message-ID: Randy, ok, thanks it sounds like you did one of the two things. 1) Remerge old diffs to new tree. but not 2) Lift out what is common into a common file, instead of forking the entire file. I didn't mean to imply Unix gui should look like Windows gui. Just that the large amounts of common code should not be duplicated. Probably what'd work is have one merged file with some if's sprinkled. I think what Unix gui should look like is a perpetually unsolved problem and the answer is somewhere between "terrible" and "like Windows", with KDE at least near the second extreme. :) Trestle seems to be among the uglier Unix gui libraries actually.. It'd be nice if there was an option to adapt to the current "theme", but Trestle to me is a very large unknown.. - Jay Date: Sun, 13 Dec 2009 00:02:34 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:12:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:12:21 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: <4B242FF0.1E75.00D7.1@scires.com> Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:16:31 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:16:31 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: , <4B242C23.1E75.00D7.1@scires.com> Message-ID: <4B2430EA.1E75.00D7.1@scires.com> Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. Regards, Randy >>> Jay K 12/12/2009 11:56 PM >>> Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:13:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:13:09 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:15:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:15:49 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: [pesky truncation again!] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] FW: Win32/ScrollerVBTClass.m3 Date: Sun, 13 Dec 2009 05:13:09 +0000 Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:22:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:22:25 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com> Message-ID: <4B24324C.1E75.00D7.1@scires.com> Jay: You are correct that I did not attempt to factor out common code. At the time, we were more interested in correct behavior, and such factoring did not provide any benefits to the executing code. The benefit of such factoring is in reducing the source tree size and potentially improved maintainability, if done right. So to that end, I applaud your efforts. Regards, Randy >>> Jay K 12/13/2009 12:04 AM >>> Randy, ok, thanks it sounds like you did one of the two things. 1) Remerge old diffs to new tree. but not 2) Lift out what is common into a common file, instead of forking the entire file. I didn't mean to imply Unix gui should look like Windows gui. Just that the large amounts of common code should not be duplicated. Probably what'd work is have one merged file with some if's sprinkled. I think what Unix gui should look like is a perpetually unsolved problem and the answer is somewhere between "terrible" and "like Windows", with KDE at least near the second extreme. :) Trestle seems to be among the uglier Unix gui libraries actually.. It'd be nice if there was an option to adapt to the current "theme", but Trestle to me is a very large unknown.. - Jay Date: Sun, 13 Dec 2009 00:02:34 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:37:55 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:37:55 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <4B2435EE.1E75.00D7.1@scires.com> Jay: My recollection is that I had multiple source trees to work with, including the then current repository, my original 4.1 source tree, and the modified 4.1 source tree we got from Farshad. There may have been others; I don't remember; its been a while. I also vaguely recall doing some comparisons against the DEC SRC sources, which I also had. I never used mentor, so I can't comment there. As far as whether Modula-3 is still ahead of its time, I think the work we are all doing is necessary if the language is to survive. Right now, I think we are playing catch up in terms of having viable implementations on a sufficient base of modern OS and processors. I still prefer Modula-3 as a language and I think it has a lot to offer. >From an educational standpoint, I can't think of a better language for one to learn good programming principles and practices. Perhaps if more computer science students started out with Modula-3 the world would be a better place... Back when Microsoft first came out with .NET, I seriously considered working on a Modula-3 implementation for .NET and talked with some folks at Microsoft about it, but my career and family kept me busy and I never got very far. Regards, Randy >>> Jay K 12/13/2009 12:13 AM >>> Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:34:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:34:21 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? Message-ID: https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:38:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:38:46 +0000 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: <4B2430EA.1E75.00D7.1@scires.com> References: , , <4B242C23.1E75.00D7.1@scires.com>, , <4B2430EA.1E75.00D7.1@scires.com> Message-ID: The 4.1 code has the bug (this is probably identical but I haven't done a mechanical diff, but it is plain to see it has the bug): (I bought 4.1 too). PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1000.0D0)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; - Jay Date: Sun, 13 Dec 2009 00:16:31 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. Regards, Randy >>> Jay K 12/12/2009 11:56 PM >>> Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:42:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:42:19 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: Message-ID: I seem to have quite a knack for placing periods in column 76 by accident. This was truncated right at the end. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 13 Dec 2009 05:34:21 +0000 > Subject: [M3devel] pickle bug..solved?.. not supposed to work? > > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:52:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:52:53 -0500 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: Message-ID: <4B243970.1E75.00D7.1@scires.com> Jay: I've done a lot with Pickles and with NetObj. I switched to the v2 version a long time ago and never looked back. IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. Regards, Randy >>> Jay K 12/13/2009 12:34 AM >>> https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:47:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:47:29 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: I keep trying to understand Trestle but I keep failing. I tried to read the comments explaining how its locking works and I got lost quickly. I suspect that compares well to other GUI libraries in that they probably just don't do threading well. Easy to understand though. The Trestle apps are all pretty ugly and oddly behaved. Granted, I have no "real use" for them. I just exercise them a bit as test cases. I did notice you made the scrollbars look "nice" on Windows. The close box is marked "C". The grow box is marked "G". Yuck. As I said though, the more I look into Trestle, the more I think it is implementing a rather complete "windows system" and not just a library of widgets, nor even widgets + resizing algorithms. Nor even just widgets + resizing + event routing. Like, it seems to also manage clipping, knowing what needs redrawing, etc. But I'm not sure. It adds up to a lot of code, is my concern. That is good and bad. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:50:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:50:59 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <4B243970.1E75.00D7.1@scires.com> References: , <4B243970.1E75.00D7.1@scires.com> Message-ID: I assume there is a need to keep the code around for compatibility? You know -- to read existing files? And to keep testing that? And write them at least so the tests can read them back? But maybe we should take a read-only attitude? And switch the quake netobj=netobj1 to netobj=netobj2? It's tough..if you convert-upon-write, and people are running old programs, you'll break their files. It's also tough, you know, I think this stuff is too automatic. I'm pretty sure we should change the Text internal representation, but I'm also pretty sure the persistance (disk) representation is automatically derived from the transient (memory) representation and changing the second breaks the first. You know, I suspect it is like those systems that do: struct foo a; fwrite(&a, sizeof(a)); but just with endian/wordsize conversions and hashes/typeid to do checks upon read, so it won't crash if you change things, but it also won't read back successfully. Maybe the v1 limitations are good as well, in that maybe it is faster, and sometimes the limitations don't matter??? - Jay Date: Sun, 13 Dec 2009 00:52:53 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? Jay: I've done a lot with Pickles and with NetObj. I switched to the v2 version a long time ago and never looked back. IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. Regards, Randy >>> Jay K 12/13/2009 12:34 AM >>> https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:10:40 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:10:40 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: , , <4B242C23.1E75.00D7.1@scires.com>, , <4B2430EA.1E75.00D7.1@scires.com> Message-ID: <751737BC-0080-4F0C-975E-11C17246937F@cs.purdue.edu> Given that I based pthreads on win32 its no surprise that I replicated the bug. I've fixed it in ThreadPThread on the trunk. Probably needs copying over to the release branch. On 13 Dec 2009, at 00:38, Jay K wrote: > The 4.1 code has the bug (this is probably identical but I haven't done a mechanical diff, > but it is plain to see it has the bug): > (I bought 4.1 too). > > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = > VAR amount, thisTime: LONGREAL; > CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; > VAR self: T; > BEGIN > self := Self(); > amount := n; > WHILE amount > 0.0D0 DO > thisTime := MIN (Limit, amount); > amount := amount - thisTime; > WinBase.EnterCriticalSection(cm); > InnerTestAlert(self); > self.alertable := TRUE; > <* ASSERT(self.waitingOn = NIL) *> > WinBase.LeaveCriticalSection(cm); > EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1000.0D0)); > WinBase.EnterCriticalSection(cm); > self.alertable := FALSE; > IF self.alerted THEN > (* Sadly, the alert might have happened after we timed out on the > semaphore and before we entered "cm". In that case, we need to > decrement the semaphore's count *) > EVAL WinBase.WaitForSingleObject(self.waitSema, 0); > InnerTestAlert(self); > END; > WinBase.LeaveCriticalSection(cm); > END; > END AlertPause; > > - Jay > > > > Date: Sun, 13 Dec 2009 00:16:31 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] AlertPause(0) is alertable? > > Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. > Regards, > Randy > > >>> Jay K 12/12/2009 11:56 PM >>> > Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. > > > Note that the 3.6 code doesn't seem to get it right: > > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = > VAR amount, thisTime: LONGREAL; > CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; > VAR self: T; > BEGIN > self := Self(); > amount := n; > WHILE amount > 0.0D0 DO > thisTime := MIN (Limit, amount); > amount := amount - thisTime; > WinBase.EnterCriticalSection(cm); > InnerTestAlert(self); > self.alertable := TRUE; > <* ASSERT(self.waitingOn = NIL) *> > WinBase.LeaveCriticalSection(cm); > EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); > WinBase.EnterCriticalSection(cm); > self.alertable := FALSE; > IF self.alerted THEN > (* Sadly, the alert might have happened after we timed out on the > semaphore and before we entered "cm". In that case, we need to > decrement the semaphore's count *) > EVAL WinBase.WaitForSingleObject(self.waitSema, 0); > InnerTestAlert(self); > END; > WinBase.LeaveCriticalSection(cm); > END; > END AlertPause; > > The 3.6 and current user threads code seems ok, but I've not very familiar with it. > > This might be one of those things though that's been consistently broken for so long that it's best not to depend on? > Prefer AlertPause(0.01) over AlertPause(0)?? > > > - Jay > > > > Date: Sat, 12 Dec 2009 23:56:08 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] AlertPause(0) is alertable? > > My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. > > Regards, > Randy > > >>> Jay K 12/12/2009 7:37 PM >>> > If I call AlertPause with <= 0 time, should I recieve alerts? > Current pthread/win32 implementations: no. > They say if time <= then return end before doing much. > My suspicion: yes. > > > Thread.i3: > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; > (* Like "Pause", but if the thread is marked alerted at the time of > the call or sometime during the wait, raise "Alerted". *) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:11:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:11:44 -0500 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: , <4B243970.1E75.00D7.1@scires.com> Message-ID: <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> Yes, v1 is there in case anyone has v1 pickles they want to decode. On 13 Dec 2009, at 00:50, Jay K wrote: > I assume there is a need to keep the code around for compatibility? > You know -- to read existing files? > And to keep testing that? > And write them at least so the tests can read them back? > > > But maybe we should take a read-only attitude? > > > And switch the quake netobj=netobj1 to netobj=netobj2? > > > It's tough..if you convert-upon-write, and people are > running old programs, you'll break their files. > > > It's also tough, you know, I think this stuff is too automatic. > I'm pretty sure we should change the Text internal representation, > but I'm also pretty sure the persistance (disk) representation > is automatically derived from the transient (memory) > representation and changing the second breaks the first. > > > You know, I suspect it is like those systems > that do: > > > struct foo a; > fwrite(&a, sizeof(a)); > > > but just with endian/wordsize conversions and > hashes/typeid to do checks upon read, so it > won't crash if you change things, but it also won't > read back successfully. > > > Maybe the v1 limitations are good as well, in that maybe > it is faster, and sometimes the limitations don't matter??? > > > - Jay > > > Date: Sun, 13 Dec 2009 00:52:53 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? > > Jay: > > I've done a lot with Pickles and with NetObj. > > I switched to the v2 version a long time ago and never looked back. > > IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. > > Regards, > Randy > > >>> Jay K 12/13/2009 12:34 AM >>> > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Dec 13 19:09:57 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 13 Dec 2009 12:09:57 -0600 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <4B243970.1E75.00D7.1@scires.com> References: <4B243970.1E75.00D7.1@scires.com> Message-ID: <4B252DF5.7020400@lcwb.coop> Randy Coleburn wrote: > Jay: > > I've done a lot with Pickles and with NetObj. > > I switched to the v2 version a long time ago and never looked back. > > IMO, we should switch over to v2 exclusively and consider v1 > obsolete. Perhaps some others should comment on this to see if they > share my opinion. I am using pickles and have done work inside pickle code. I agree strongly on this. V2 pickle code can read pickle files written by V1 pickle code (or at least V2 pickles have code that appears to do so), so old pickle files can still be read. This adaptation is made at dynamically at read time by looking at the pickle file header, so no user action is required. So there is really no benefit to using V1 pickle code. There is one thing that has been a problem for me in the past. In PM3, importing "Pickle" gets you version 2, while in CM3, "Pickle" gets you V1 and you have to import "Pickle2" to get V2. This means code that is to compile/run in either PM3 or CM3 has to have changes to actual source code. I have scripted this, but it is a messy and fragile kludge. I will probably drop maintaining PM3/CM3 compilability in the future. Anybody else doing this? There is one other messy problem that comes to mind. Both versions have a few hard-coded signatures for a few language-predefined types that do not consistently follow the byte order used in type signatures in general. They differ both between the versions and from the general rule. In some case(s), the byte ordering used is downright bizarre. I don't remember for certain, but I think I fixed V2 to adapt to V1's conventions on this when reading V1 pickle files. > > Regards, > Randy > > >>> Jay K 12/13/2009 12:34 AM >>> > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with > pickles From hosking at cs.purdue.edu Sun Dec 13 19:28:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:28:23 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: <75934296-836C-4024-B61B-1321002FB567@cs.purdue.edu> Trestle is of historic interest to the M3 community. We should try to keep it living and breathing. On 12 Dec 2009, at 22:46, Jay K wrote: > eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. > scrollertvbtclass is pretty close, though current adds "shadows". > Maybe we're ok in practise, but I still don't like it. > > (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging > feeling that Trestle reinvents far more than most other gui libraries.) > > - Jay > > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Sun, 13 Dec 2009 03:41:25 +0000 > Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 > > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:30:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:30:18 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242DA5.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> Message-ID: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > Jay: > > Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. > > Regards, > Randy > > >>> Jay K 12/12/2009 10:41 PM >>> > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 02:43:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 01:43:56 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: Randy's changes make the Windows GUI look more like Windows. My changes make mentor not crash starting up just by checking for NIL and taking a lock. I don't understand Trestle's locking and the comments explaining it were too long for me to understand, so I'm just guessing. Given how ugly and non-uniform X Windows GUIs tend to be, Trestle being a good example -- it has its own unique ugly look, changing is not a bad idea, but not done here. - Jay From: hosking at cs.purdue.edu Date: Sun, 13 Dec 2009 13:30:18 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 14 12:42:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Dec 2009 12:42:57 +0100 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> References: , <4B243970.1E75.00D7.1@scires.com> <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> Message-ID: <20091214124257.35dc33zjnkws0ks0@mail.elegosoft.com> Quoting Tony Hosking : > Yes, v1 is there in case anyone has v1 pickles they want to decode. I'd also vote for making V2 pickles the default. We could rename Pickle to Pickle1 and Pickle2 to Pickle and document this as an semantically incompatible change. Or is there really much interest in reading old pickle versions? Olaf > On 13 Dec 2009, at 00:50, Jay K wrote: > >> I assume there is a need to keep the code around for compatibility? >> You know -- to read existing files? >> And to keep testing that? >> And write them at least so the tests can read them back? >> >> >> But maybe we should take a read-only attitude? >> >> >> And switch the quake netobj=netobj1 to netobj=netobj2? >> >> >> It's tough..if you convert-upon-write, and people are >> running old programs, you'll break their files. >> >> >> It's also tough, you know, I think this stuff is too automatic. >> I'm pretty sure we should change the Text internal representation, >> but I'm also pretty sure the persistance (disk) representation >> is automatically derived from the transient (memory) >> representation and changing the second breaks the first. >> >> >> You know, I suspect it is like those systems >> that do: >> >> >> struct foo a; >> fwrite(&a, sizeof(a)); >> >> >> but just with endian/wordsize conversions and >> hashes/typeid to do checks upon read, so it >> won't crash if you change things, but it also won't >> read back successfully. >> >> >> Maybe the v1 limitations are good as well, in that maybe >> it is faster, and sometimes the limitations don't matter??? >> >> >> - Jay >> >> >> Date: Sun, 13 Dec 2009 00:52:53 -0500 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? >> >> Jay: >> >> I've done a lot with Pickles and with NetObj. >> >> I switched to the v2 version a long time ago and never looked back. >> >> IMO, we should switch over to v2 exclusively and consider v1 >> obsolete. Perhaps some others should comment on this to see if >> they share my opinion. >> >> Regards, >> Randy >> >> >>> Jay K 12/13/2009 12:34 AM >>> >> >> https://projects.elego.de/cm3/ticket/1068 >> >> >> >> >> >> I've only spent a few minutes here. >> >> Trying to find the relative code and such. >> >> >> >> >> >> The code is here: >> >> >> >> >> >> C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src >> >> >> >> I found it by looking near the top of the stack in >> >> the bug report -- NetObjTest.m3 -- and >> >> then dir /s/b NetObjTest.m3. >> >> >> >> or find . | grep NetObjTest.m3$ on Unix. >> >> >> >> >> >> It appears that Pickle v1 and v2 are both >> >> available in the same library. >> >> There is INTERFACE Pickle and INTERFACE Pickle2. >> >> >> >> >> >> It appears netobj can use either. >> >> >> >> If you look at the stack in the bug, there is a lot of "v1" stuff. >> >> >> >> >> >> We provide Quake functions: >> >> >> >> readonly proc netobjv1(intf, type) is >> ... >> >> end >> >> >> >> readonly proc Netobjv1(intf, type) is >> ... >> >> end >> >> >> >> readonly proc netobjv2(intf, type) is >> ... >> >> end >> >> >> >> readonly proc netobj(intf, type) is >> netobjv1(intf, type) >> end >> >> >> >> >> >> >> v1 pickles cannot cross endian/wordsize boundaries. >> >> >> >> >> >> I think the bug is not so much in the pickle code, nor in the netobj code, >> >> but in the test code, or the running of it. >> >> >> >> Tests involving v1 won't work crossing endian/wordsize boundaries. >> >> V1 tests probably should still run, and maybe detect the mismatch >> >> and just claim success? >> >> >> >> And then v2 should get better coverage? >> >> >> >> >> >> Any more bugs then? >> >> I was procrastinating on this because I've never done anything with pickles > > -- 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 From wagner at elegosoft.com Mon Dec 14 12:59:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Dec 2009 12:59:50 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> Quoting Jay K : > I keep trying to understand Trestle but I keep failing. > I tried to read the comments explaining how its locking > works and I got lost quickly. Actually the Trestle locking was `verified' after the implementation was finished with the Extended Statical Checker written at that time in Modula-3, too (but reimplemented since then in Java). See SRC report 159, for example here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 This is where all the locking level pragmas come from. > I suspect that compares well to other GUI libraries > in that they probably just don't do threading well. I always thought that using threads extensively to keep the application responding to user request was one of the strong areas of Testle. > Easy to understand though. > > The Trestle apps are all pretty ugly and oddly behaved. > Granted, I have no "real use" for them. I just exercise > them a bit as test cases. > > I did notice you made the scrollbars look "nice" on Windows. > > The close box is marked "C". > The grow box is marked "G". I grant that making it look better would probably increase the user acceptance. IMO there's no reason not to do that; but there hasn't been anybody interested in working on it yet. > Yuck. > > As I said though, the more I look into Trestle, the more I think > it is implementing a rather complete "windows system" and not > just a library of widgets, nor even widgets + resizing algorithms. > Nor even just widgets + resizing + event routing. > > Like, it seems to also manage clipping, knowing what needs > redrawing, etc. > > But I'm not sure. > > It adds up to a lot of code, is my concern. > > That is good and bad. Yes. But it's a huge project to integrate another GUI library into M3 and make it as useful as Trestle. 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 From jay.krell at cornell.edu Mon Dec 14 13:52:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 12:52:12 +0000 Subject: [M3devel] darwin user threads? Message-ID: It looks like make/get/set/swapcontext aren't viable on MacOSX 10.5. Better on 10.6? x86 getcontext seems to corrupt things such that a crash follows shortly. AMD64 just doesn't work. I happen to be experimenting again with see http://www.engelschall.com/pw/usenix/2000/pmt-html/ again to ease OpenBSD porting..and had some luck on Darwin, though had trouble getting the timer to trigger ever or more than once. $ cat 1.c && gcc -m32 1.c && file a.out && ./a.out ; gcc -m64 1.c && file a.out && ./a.out #include #include #include int main() { ucontext_t a; int b = getcontext(&a); printf("%d %d\n", b, errno); return 0; } a.out: Mach-O executable i386 0 0 Segmentation fault a.out: Mach-O 64-bit executable x86_64 -1 45 $ grep 45 /usr/include/sys/errno.h #define ENOTSUP 45 /* Operation not supported */ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 13:58:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 12:58:02 +0000 Subject: [M3devel] darwin user threads? In-Reply-To: References: Message-ID: oh, search the web for "Darwin getcontext": http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 14 Dec 2009 12:52:12 +0000 Subject: [M3devel] darwin user threads? It looks like make/get/set/swapcontext aren't viable on MacOSX 10.5. Better on 10.6? x86 getcontext seems to corrupt things such that a crash follows shortly. AMD64 just doesn't work. I happen to be experimenting again with see http://www.engelschall.com/pw/usenix/2000/pmt-html/ again to ease OpenBSD porting..and had some luck on Darwin, though had trouble getting the timer to trigger ever or more than once. $ cat 1.c && gcc -m32 1.c && file a.out && ./a.out ; gcc -m64 1.c && file a.out && ./a.out #include #include #include int main() { ucontext_t a; int b = getcontext(&a); printf("%d %d\n", b, errno); return 0; } a.out: Mach-O executable i386 0 0 Segmentation fault a.out: Mach-O 64-bit executable x86_64 -1 45 $ grep 45 /usr/include/sys/errno.h #define ENOTSUP 45 /* Operation not supported */ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 16:10:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 10:10:37 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> Do you mean mentor crashing on Windows? I would not like us to introduce new bugs to X11-based Trestle by merging Windows with X11 Trestle. On 13 Dec 2009, at 20:43, Jay K wrote: > Randy's changes make the Windows GUI look more like > Windows. My changes make mentor not crash starting > up just by checking for NIL and taking a lock. > I don't understand Trestle's locking and the comments > explaining it were too long for me to understand, > so I'm just guessing. > > Given how ugly and non-uniform X Windows GUIs tend to be, > Trestle being a good example -- it has its own > unique ugly look, changing is not a bad idea, > but not done here. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Sun, 13 Dec 2009 13:30:18 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 > > Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. > > > On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > > Jay: > > Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. > > Regards, > Randy > > >>> Jay K 12/12/2009 10:41 PM >>> > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 16:14:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 10:14:33 -0500 Subject: [M3devel] darwin user threads? In-Reply-To: References: Message-ID: <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> I knew about this issue at the time I implemented user threads and extensively tested it successfully on my OS X 10.5 laptop. It must have gotten broken when you reorganized everything. Can you put the _XOPEN_SOURCE define back in please! On 14 Dec 2009, at 07:58, Jay K wrote: > > oh, search the web for "Darwin getcontext": > > http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html > > Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 16:14:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 15:14:40 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242DA5.1E75.00D7.1@scires.com>, , <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, , <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> Message-ID: Yes it was crashing on Windows. It wasn't really "Windows-specific", it was specifically in the code Randy added. The two files are largely the same and they are both portable. It's just a matter of what pictures get drawn using the same underlying Trestle graphics functions. That is, the code is portable either way, it's just a behaviorial/visual decision that is made. You know, you could perfectly well allow: mentor -gui-style=windows mentor -gui-style=trestle You know, this isn't low level code, it is "middle". - Jay From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:10:37 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Do you mean mentor crashing on Windows? I would not like us to introduce new bugs to X11-based Trestle by merging Windows with X11 Trestle. On 13 Dec 2009, at 20:43, Jay K wrote:Randy's changes make the Windows GUI look more like Windows. My changes make mentor not crash starting up just by checking for NIL and taking a lock. I don't understand Trestle's locking and the comments explaining it were too long for me to understand, so I'm just guessing. Given how ugly and non-uniform X Windows GUIs tend to be, Trestle being a good example -- it has its own unique ugly look, changing is not a bad idea, but not done here. - Jay From: hosking at cs.purdue.edu Date: Sun, 13 Dec 2009 13:30:18 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote:Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards,Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 16:17:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 15:17:20 +0000 Subject: [M3devel] darwin user threads? In-Reply-To: <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> References: , <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> Message-ID: I didn't break it. It is not broken. I was "unhappy" at the non portability I had setup for OpenBSD..was trying sigaltstack again..was testing on Mac.. - Jay Subject: Re: [M3devel] darwin user threads? From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:14:33 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I knew about this issue at the time I implemented user threads and extensively tested it successfully on my OS X 10.5 laptop. It must have gotten broken when you reorganized everything. Can you put the _XOPEN_SOURCE define back in please! On 14 Dec 2009, at 07:58, Jay K wrote: oh, search the web for "Darwin getcontext": http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Dec 14 17:31:01 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 14 Dec 2009 08:31:01 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20091214134015.9044F2474001@birch.elegosoft.com>, , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu> Message-ID: <20091214163101.109F61A2078@async.async.caltech.edu> Alpha is little-endian because it's DEC and all DEC systems are little-endian. It's one of those religious wars, now long forgotten... DEC did win that war, after all, but much good it did them. Also regarding Trestle: there are several tech reports about it that explain the locking schemes in detail. Are there really other windowing systems out there that have similarly good support for multithreaded programs? (I've certainly never seen one...I think Trestle is very very cool.) Mika Jay K writes: >--_53b61834-1f8f-4857-9285-039cb0730d0c_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I assumed Alpha was little endian because it ran NT. >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > Linux and AIX?) > >Target.m3: > > (* big endian *) > > IF TextUtils.StartsWith(system=2C "PA") > > (* MIPS is definitely ambiguous! *) > OR TextUtils.StartsWith(system=2C "MIPS") > =20 > (* PPC is a little ambiguous? *) > OR TextUtils.StartsWith(system=2C "PPC") > > OR TextUtils.StartsWith(system=2C "SPARC") > OR TextUtils.StartsWith(system=2C "SOL") THEN > Little_endian :=3D FALSE=3B > END=3B > >Anyway it shouldn't be hard to track down. >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= >ng around...) > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= >s correct=2C and it /has/ no survived a fair number of combinations. I do c= >ross builds /almost/ without considering host and target. Er=2C except you = >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= >as started hitting me more often... it's just something where the compiler = >gets confused and does host math with target limitations=2C where it should= > do target math. > > - Jay > >From: hosking at cs.purdue.edu >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 >To: jay.krell at cornell.edu >CC: m3commit at elegosoft.com >Subject: Re: [M3commit] CVS Update: cm3 > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > code. I rewrote it=2C at least once. >Cross compiling works. >Native does not. >It must be the threshold variables in RTCollector. > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > earliest use of FP in the run-time linker. If they are broken you find ou= >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = >one point just fine on native Alpha 64-bit=2C so should not be too hard to = >fix. >I really thought I understood that code. > > - Jay > > >From: hosking at cs.purdue.edu >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 >To: jkrell at elego.de >CC: m3commit at elegosoft.com >Subject: Re: [M3commit] CVS Update: cm3 > >This suggests an m3cg backend compiler problem for floating point on SPARC6= >4. >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs >Changes by: jkrell at birch. 09/12/14 14:40:15 > >Modified files: > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > cm3/m3-libs/m3core/src/unix/: m3makefile=20 >Removed files: > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > >Log message: > updates so SPARC64_SOLARIS bootstrap can build > (possible tangent related to getting SPARC64_OPENBSD > to work -- problem apparently with the floating point > constants in RTCollector=2C such that Behind() is > always TRUE=2C even for the first allocation=2C so > access violate trying to garbage collect too > early=2C when self is still NULL) > > > = > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= >w=2C a lot of chips go either way these days (PowerPC little endian for NT = >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?)>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = >has been sitting around...)

The code I put in parse.c is definitely = >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = >fair number of combinations. I do cross builds /almost/ without considering= > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= >obably fix that pretty soon as it has started hitting me more often... it's= > just something where the compiler gets confused and does host math with ta= >rget limitations=2C where it should do target math.

 =3B- Jay>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> >
parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= >transform: none=3B white-space: normal=3B word-spacing: 0px=3B">=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= >te-space: normal=3B word-spacing: 0px=3B">
rd=3B">te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B">"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= >e-space: normal=3B word-spacing: 0px=3B">" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= >d-spacing: 0px=3B">apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= >ne=3B white-space: normal=3B word-spacing: 0px=3B">style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > 0px=3B">rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= >=2C at 10:43=2C Jay K wrote:
>

interchange-newline">
=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= >mpiling works.
Native does not.
It must be the threshold variables in= > RTCollector.

Yeah=2C I've= > been bitten by just that scenario in the past -- those are the earliest us= >e of FP in the run-time linker.  =3BIf they are broken you find out qui= >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > hard to fix.

e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= >ally thought I understood that code.

 =3B- Jay


=3D"ecxstopSpelling">From: =3B= >hosking at cs.purdue.edur>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To:verted-space"> =3Bjkrell at eleg= >o.de
CC: =3Bref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= >: Re: [M3commit] CVS Update: cm3

le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= >=3B word-spacing: 0px=3B">order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= >px=3B">
tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= >al=3B word-spacing: 0px=3B">"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > 0px=3B">eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= >ng: 0px=3B">: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">
Apple-style-span" style=3D"font-size: medium=3B">-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= >ackend compiler problem for floating point on SPARC64.
<= >/span>
= >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= >e:

CVSR= >OOT: pan>/usr/cvs
Changes by:ite-space: pre=3B"> jkrell at birch." style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= >iles:
> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 class=3D"ecxApple-converted-space"> =3B
xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= >rc/unix/: m3makefile =3B>
Removed files:
space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= >ignal.m3 =3B

Log= > message:
=3B"> updates so SPARC64_SOLARIS bootstrap can build
=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= >angent related to getting SPARC64_OPENBSD
-span" style=3D"white-space: pre=3B"> to work -- problem apparently = >with the floating point
ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= >s
span>always TRUE=2C even for the first allocation=2C so
cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= >rying to garbage collect too
=3D"white-space: pre=3B"> early=2C when self is still NULL)
>


ine">

>= > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- From jay.krell at cornell.edu Mon Dec 14 17:31:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:31:29 +0000 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). It still seemed to hang. (I realize you might not have meant that.) So what happens if none of our user threads have any work? Is that possible? Sure, I can make it so. Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). Will they actually wake up after that time? And we won't spin the CPU in the meantime? I guess I should test it out.. I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. But I wonder also..you have OpenBSD/x86 or sparc64? cd to that test bed, make, ./tcontext. It always seemed kind of jerky. I bet it'll seem "faster" with "real" timer. - Jay From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:39:31 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Main thread should call Yield if you want that behavior, not sleep. On 14 Dec 2009, at 14:57, Jay Krell wrote:CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/12/14 14:57:30 Added files: cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: Makefile config.c context.c context.h m3makefile tcontext.c Log message: working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ - This should be moved to m3core/src/thread/POSIX - Notice how I switched from virtual timer to real timer, in the test case that mimics m3core/src/thread/POSIX. "This seems to work much better." In particular, if the main thread does while (1) sleep(0) to let things run, nothing runs. The virtual time doesn't run down at all. If I make it a busy wait "while (1) ;" then it does work. Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). This solution might be preferred? Though it is slower to create a thread here, due to extra gymnastics to establish the initial context. Also still some experiments to try. _setjmp vs. setjmp vs. sigsetjmp. Best is probably sigsetjmp(1). using the same signal in both parts -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 17:39:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:39:40 +0000 Subject: [M3devel] Trestle In-Reply-To: <20091214163101.109F61A2078@async.async.caltech.edu> References: <20091214134015.9044F2474001@birch.elegosoft.com>, , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu> , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: I'm pretty sure Win32 doesn't have great GUI threading. Each Window has affinity to the thread it is created on -- all events to it are delivered to that thread. I'm pretty sure Java doesn't have great GUI threading. I remember historically that the X client (Xlib) wasn't historically even thread safe. However the server must be, since it is interacting with multiple processes. I doubt Trestle an really overcome the limits of the underlying systems though. My wording was poor. I can't remove Trestle, of course. But providing an alternative is still not a terrible idea. All my "research" (highly non scientific) says Qt is the way. As to how/if it would fit into Modula-3, I have little idea..and not a lot of time/interest either. The results generally look and behave better imho. The platform support (esp. Windows) is better. I'm aware that there are /many/ options and I'm aware of the unclear licensing issues. Probably it is one of those things that is free for use by "open source", and we probably quality, but not free for commercial use. Really, though, nothing going on here. Not worth arguing about. (Maybe I'll "merge" the X/Win32 Scroller, so that it is one body of code with ifs, but I'd leave X looking as it does (ugly), just reducing overall code volume and probably increasing maintainability (they don't directly correspond, but often largely do). - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 14 Dec 2009 08:31:01 -0800 > From: mika at async.async.caltech.edu > > > Alpha is little-endian because it's DEC and all DEC systems are > little-endian. It's one of those religious wars, now long forgotten... > DEC did win that war, after all, but much good it did them. > > Also regarding Trestle: there are several tech reports about it that > explain the locking schemes in detail. Are there really other windowing > systems out there that have similarly good support for multithreaded > programs? (I've certainly never seen one...I think Trestle is very > very cool.) > > Mika > > Jay K writes: > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I assumed Alpha was little endian because it ran NT. > >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= > >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > > Linux and AIX?) > > > >Target.m3: > > > > (* big endian *) > > > > IF TextUtils.StartsWith(system=2C "PA") > > > > (* MIPS is definitely ambiguous! *) > > OR TextUtils.StartsWith(system=2C "MIPS") > > =20 > > (* PPC is a little ambiguous? *) > > OR TextUtils.StartsWith(system=2C "PPC") > > > > OR TextUtils.StartsWith(system=2C "SPARC") > > OR TextUtils.StartsWith(system=2C "SOL") THEN > > Little_endian :=3D FALSE=3B > > END=3B > > > >Anyway it shouldn't be hard to track down. > >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= > >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= > >ng around...) > > > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= > >s correct=2C and it /has/ no survived a fair number of combinations. I do c= > >ross builds /almost/ without considering host and target. Er=2C except you = > >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= > >as started hitting me more often... it's just something where the compiler = > >gets confused and does host math with target limitations=2C where it should= > > do target math. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 > >To: jay.krell at cornell.edu > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > > code. I rewrote it=2C at least once. > >Cross compiling works. > >Native does not. > >It must be the threshold variables in RTCollector. > > > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > > earliest use of FP in the run-time linker. If they are broken you find ou= > >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = > >one point just fine on native Alpha 64-bit=2C so should not be too hard to = > >fix. > >I really thought I understood that code. > > > > - Jay > > > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 > >To: jkrell at elego.de > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > >This suggests an m3cg backend compiler problem for floating point on SPARC6= > >4. > >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/12/14 14:40:15 > > > >Modified files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > > cm3/m3-libs/m3core/src/unix/: m3makefile=20 > >Removed files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > > > >Log message: > > updates so SPARC64_SOLARIS bootstrap can build > > (possible tangent related to getting SPARC64_OPENBSD > > to work -- problem apparently with the floating point > > constants in RTCollector=2C such that Behind() is > > always TRUE=2C even for the first allocation=2C so > > access violate trying to garbage collect too > > early=2C when self is still NULL) > > > > > > = > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= > >w=2C a lot of chips go either way these days (PowerPC little endian for NT = > >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?) >>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= > >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= > >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = > >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = > >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= > >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= > >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= > >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= > >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= > >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= > >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= > >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = > >has been sitting around...)

The code I put in parse.c is definitely = > >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = > >fair number of combinations. I do cross builds /almost/ without considering= > > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= > >obably fix that pretty soon as it has started hitting me more often... it's= > > just something where the compiler gets confused and does host math with ta= > >rget limitations=2C where it should do target math.

 =3B- Jay >>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= > >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> > > >
>parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= > >transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= > >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= > >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= > >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= > >te-space: normal=3B word-spacing: 0px=3B">
>rd=3B"> >te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= > >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= > >=2C at 10:43=2C Jay K wrote:
 >>

>interchange-newline">
>=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= > >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = > >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= > >mpiling works.
Native does not.
It must be the threshold variables in= > > RTCollector.

Yeah=2C I've= > > been bitten by just that scenario in the past -- those are the earliest us= > >e of FP in the run-time linker.  =3BIf they are broken you find out qui= > >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= > >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > > hard to fix.

>e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= > >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = > >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= > >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= > >ally thought I understood that code.

 =3B- Jay


>=3D"ecxstopSpelling">From: =3B= > >hosking at cs.purdue.edu >r>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To: >verted-space"> =3Bjkrell at eleg= > >o.de
CC: =3B >ref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= > >: Re: [M3commit] CVS Update: cm3

>le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= > >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= > >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= > >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= > >=3B word-spacing: 0px=3B"> >order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= > >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= > >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= > >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= > >px=3B">
>tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= > >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= > >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= > >al=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = > >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= > >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= > >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= > >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B"> >-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= > >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= > >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= > >ng: 0px=3B"> >: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= > >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= > >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= > >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= > >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= > >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= > >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B">
>Apple-style-span" style=3D"font-size: medium=3B"> >-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= > >ackend compiler problem for floating point on SPARC64.
<= > >/span>
= > >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= > >e:

CVSR= > >OOT: >pan>/usr/cvs
Changes by: >ite-space: pre=3B"> jkrell at birch. >" style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= > >iles:
>> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 > class=3D"ecxApple-converted-space"> =3B
>xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= > >rc/unix/: m3makefile =3B >>
Removed files:
>space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= > >ignal.m3 =3B

Log= > > message:
>=3B"> updates so SPARC64_SOLARIS bootstrap can build
>=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= > >angent related to getting SPARC64_OPENBSD
>-span" style=3D"white-space: pre=3B"> to work -- problem apparently = > >with the floating point
>ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= > >s
>span>always TRUE=2C even for the first allocation=2C so
>cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= > >rying to garbage collect too
>=3D"white-space: pre=3B"> early=2C when self is still NULL)
>>


>ine">

> >= > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 17:43:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:43:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091214163101.109F61A2078@async.async.caltech.edu> References: <20091214134015.9044F2474001@birch.elegosoft.com>, , , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , , , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu>, , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: >> all DEC systems are little-endian Ok, educate me. VAX little endian? MIPS-based DecStations running Ultrix little endian? (again, MIPS ran NT, but MIPS is "well known" to be "either" there's often "mips" and "mipsle", "le"="little endian") Alpha/VMS little endian? Alpha/Tru64 little endian? IA64/VMS little endian? (IA64/HPUX little endian?) (Alpha/IA64/MIPS/PPC NT yes little all endian) - Jay > To: jay.krell at cornell.edu > Date: Mon, 14 Dec 2009 08:31:01 -0800 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Alpha is little-endian because it's DEC and all DEC systems are > little-endian. It's one of those religious wars, now long forgotten... > DEC did win that war, after all, but much good it did them. > > Also regarding Trestle: there are several tech reports about it that > explain the locking schemes in detail. Are there really other windowing > systems out there that have similarly good support for multithreaded > programs? (I've certainly never seen one...I think Trestle is very > very cool.) > > Mika > > Jay K writes: > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I assumed Alpha was little endian because it ran NT. > >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= > >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > > Linux and AIX?) > > > >Target.m3: > > > > (* big endian *) > > > > IF TextUtils.StartsWith(system=2C "PA") > > > > (* MIPS is definitely ambiguous! *) > > OR TextUtils.StartsWith(system=2C "MIPS") > > =20 > > (* PPC is a little ambiguous? *) > > OR TextUtils.StartsWith(system=2C "PPC") > > > > OR TextUtils.StartsWith(system=2C "SPARC") > > OR TextUtils.StartsWith(system=2C "SOL") THEN > > Little_endian :=3D FALSE=3B > > END=3B > > > >Anyway it shouldn't be hard to track down. > >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= > >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= > >ng around...) > > > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= > >s correct=2C and it /has/ no survived a fair number of combinations. I do c= > >ross builds /almost/ without considering host and target. Er=2C except you = > >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= > >as started hitting me more often... it's just something where the compiler = > >gets confused and does host math with target limitations=2C where it should= > > do target math. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 > >To: jay.krell at cornell.edu > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > > code. I rewrote it=2C at least once. > >Cross compiling works. > >Native does not. > >It must be the threshold variables in RTCollector. > > > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > > earliest use of FP in the run-time linker. If they are broken you find ou= > >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = > >one point just fine on native Alpha 64-bit=2C so should not be too hard to = > >fix. > >I really thought I understood that code. > > > > - Jay > > > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 > >To: jkrell at elego.de > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > >This suggests an m3cg backend compiler problem for floating point on SPARC6= > >4. > >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/12/14 14:40:15 > > > >Modified files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > > cm3/m3-libs/m3core/src/unix/: m3makefile=20 > >Removed files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > > > >Log message: > > updates so SPARC64_SOLARIS bootstrap can build > > (possible tangent related to getting SPARC64_OPENBSD > > to work -- problem apparently with the floating point > > constants in RTCollector=2C such that Behind() is > > always TRUE=2C even for the first allocation=2C so > > access violate trying to garbage collect too > > early=2C when self is still NULL) > > > > > > = > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= > >w=2C a lot of chips go either way these days (PowerPC little endian for NT = > >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?) >>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= > >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= > >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = > >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = > >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= > >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= > >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= > >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= > >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= > >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= > >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= > >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = > >has been sitting around...)

The code I put in parse.c is definitely = > >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = > >fair number of combinations. I do cross builds /almost/ without considering= > > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= > >obably fix that pretty soon as it has started hitting me more often... it's= > > just something where the compiler gets confused and does host math with ta= > >rget limitations=2C where it should do target math.

 =3B- Jay >>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= > >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> > > >
>parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= > >transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= > >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= > >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= > >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= > >te-space: normal=3B word-spacing: 0px=3B">
>rd=3B"> >te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= > >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= > >=2C at 10:43=2C Jay K wrote:
 >>

>interchange-newline">
>=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= > >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = > >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= > >mpiling works.
Native does not.
It must be the threshold variables in= > > RTCollector.

Yeah=2C I've= > > been bitten by just that scenario in the past -- those are the earliest us= > >e of FP in the run-time linker.  =3BIf they are broken you find out qui= > >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= > >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > > hard to fix.

>e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= > >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = > >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= > >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= > >ally thought I understood that code.

 =3B- Jay


>=3D"ecxstopSpelling">From: =3B= > >hosking at cs.purdue.edu >r>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To: >verted-space"> =3Bjkrell at eleg= > >o.de
CC: =3B >ref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= > >: Re: [M3commit] CVS Update: cm3

>le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= > >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= > >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= > >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= > >=3B word-spacing: 0px=3B"> >order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= > >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= > >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= > >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= > >px=3B">
>tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= > >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= > >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= > >al=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = > >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= > >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= > >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= > >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B"> >-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= > >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= > >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= > >ng: 0px=3B"> >: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= > >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= > >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= > >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= > >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= > >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= > >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B">
>Apple-style-span" style=3D"font-size: medium=3B"> >-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= > >ackend compiler problem for floating point on SPARC64.
<= > >/span>
= > >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= > >e:

CVSR= > >OOT: >pan>/usr/cvs
Changes by: >ite-space: pre=3B"> jkrell at birch. >" style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= > >iles:
>> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 > class=3D"ecxApple-converted-space"> =3B
>xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= > >rc/unix/: m3makefile =3B >>
Removed files:
>space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= > >ignal.m3 =3B

Log= > > message:
>=3B"> updates so SPARC64_SOLARIS bootstrap can build
>=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= > >angent related to getting SPARC64_OPENBSD
>-span" style=3D"white-space: pre=3B"> to work -- problem apparently = > >with the floating point
>ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= > >s
>span>always TRUE=2C even for the first allocation=2C so
>cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= > >rying to garbage collect too
>=3D"white-space: pre=3B"> early=2C when self is still NULL)
>>


>ine">

> >= > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 17:55:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 11:55:14 -0500 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: <951B9075-1A76-4A45-8A13-2E8B5A2AF277@cs.purdue.edu> Scheduler.Yield()? We allow programmers to disable preemptive thread scheduling with user-level threads and simply get yields at appropriate thread primitives (LOCK, Wait, etc.). If you have a loop like that with a non-preemptive user-level thread scheduler the only way to guarantee switching is to call Yield. On 14 Dec 2009, at 11:31, Jay K wrote: > Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). > It still seemed to hang. > (I realize you might not have meant that.) > > > So what happens if none of our user threads have any work? Is that possible? > Sure, I can make it so. > Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). > Will they actually wake up after that time? > And we won't spin the CPU in the meantime? > I guess I should test it out.. > > > I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. > But I wonder also..you have OpenBSD/x86 or sparc64? > cd to that test bed, make, ./tcontext. > It always seemed kind of jerky. > I bet it'll seem "faster" with "real" timer. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 10:39:31 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Main thread should call Yield if you want that behavior, not sleep. > > On 14 Dec 2009, at 14:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/14 14:57:30 > > Added files: > cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: > Makefile > config.c > context.c > context.h > m3makefile > tcontext.c > > Log message: > working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ > - This should be moved to m3core/src/thread/POSIX > - Notice how I switched from virtual timer to real timer, > in the test case that mimics m3core/src/thread/POSIX. > "This seems to work much better." > In particular, if the main thread does while (1) sleep(0) > to let things run, nothing runs. The virtual time doesn't > run down at all. If I make it a busy wait "while (1) ;" then > it does work. > > Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). > This solution might be preferred? Though it is slower to create a thread here, due to > extra gymnastics to establish the initial context. > > Also still some experiments to try. > _setjmp vs. setjmp vs. sigsetjmp. > Best is probably sigsetjmp(1). > using the same signal in both parts > > From hosking at cs.purdue.edu Mon Dec 14 17:56:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 11:56:30 -0500 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: <4AF3AD39-F883-49AD-BB49-6C26F11A69C0@cs.purdue.edu> On 14 Dec 2009, at 11:31, Jay K wrote: > Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). > It still seemed to hang. > (I realize you might not have meant that.) > > > So what happens if none of our user threads have any work? Is that possible? > Sure, I can make it so. > Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). > Will they actually wake up after that time? Good point. Depends on what the OS timer implementation will do. We may have threads blocked on IO too, but they will wake in the select call. > And we won't spin the CPU in the meantime? > I guess I should test it out.. > > > I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. > But I wonder also..you have OpenBSD/x86 or sparc64? > cd to that test bed, make, ./tcontext. > It always seemed kind of jerky. > I bet it'll seem "faster" with "real" timer. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 10:39:31 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Main thread should call Yield if you want that behavior, not sleep. > > On 14 Dec 2009, at 14:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/14 14:57:30 > > Added files: > cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: > Makefile > config.c > context.c > context.h > m3makefile > tcontext.c > > Log message: > working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ > - This should be moved to m3core/src/thread/POSIX > - Notice how I switched from virtual timer to real timer, > in the test case that mimics m3core/src/thread/POSIX. > "This seems to work much better." > In particular, if the main thread does while (1) sleep(0) > to let things run, nothing runs. The virtual time doesn't > run down at all. If I make it a busy wait "while (1) ;" then > it does work. > > Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). > This solution might be preferred? Though it is slower to create a thread here, due to > extra gymnastics to establish the initial context. > > Also still some experiments to try. > _setjmp vs. setjmp vs. sigsetjmp. > Best is probably sigsetjmp(1). > using the same signal in both parts > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:04:18 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:04:18 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <4B262845.1E75.00D7.1@scires.com> Jay, you should only see the "C" and "G" on POSIX platforms, not Windows. We could also change the behavior on POSIX to match Windows if everyone desires, or perhaps we could provide a switch capability to choose. --Randy >>> Jay K 12/13/2009 12:47 AM >>> I keep trying to understand Trestle but I keep failing. I tried to read the comments explaining how its locking works and I got lost quickly. I suspect that compares well to other GUI libraries in that they probably just don't do threading well. Easy to understand though. The Trestle apps are all pretty ugly and oddly behaved. Granted, I have no "real use" for them. I just exercise them a bit as test cases. I did notice you made the scrollbars look "nice" on Windows. The close box is marked "C". The grow box is marked "G". Yuck. As I said though, the more I look into Trestle, the more I think it is implementing a rather complete "windows system" and not just a library of widgets, nor even widgets + resizing algorithms. Nor even just widgets + resizing + event routing. Like, it seems to also manage clipping, knowing what needs redrawing, etc. But I'm not sure. It adds up to a lot of code, is my concern. That is good and bad. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:13:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:13:37 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: <4B262A74.1E75.00D7.1@scires.com> No, I think you misinterpret what I was trying to say. I did not make any changes affecting the way the GUI looks on POSIX. The changes were only on the Windows side to make the GUI look more like Windows. These changes were based on work that Critical Mass, Inc. performed under contract to my company. We have given these changes back to the M3 community by the work I did to integrate them into the then-current source tree. I have subsequently fixed a few bugs in the code over the past couple years. Regards, Randy >>> Tony Hosking 12/13/2009 1:30 PM >>> Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 18:12:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 12:12:33 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B262A74.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> <4B262A74.1E75.00D7.1@scires.com> Message-ID: So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. 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 14 Dec 2009, at 12:13, Randy Coleburn wrote: > No, I think you misinterpret what I was trying to say. > > I did not make any changes affecting the way the GUI looks on POSIX. > > The changes were only on the Windows side to make the GUI look more like Windows. These changes were based on work that Critical Mass, Inc. performed under contract to my company. We have given these changes back to the M3 community by the work I did to integrate them into the then-current source tree. > > I have subsequently fixed a few bugs in the code over the past couple years. > > Regards, > Randy > > >>> Tony Hosking 12/13/2009 1:30 PM >>> > Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. > > > On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > >> Jay: >> >> Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. >> >> Regards, >> Randy >> >> >>> Jay K 12/12/2009 10:41 PM >>> >> 2008-05-27 02:29 rcoleburn >> >> * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, >> vbtkitresources/close.ppm, vbtkitresources/down.ppm, >> vbtkitresources/grow.ppm, vbtkitresources/left.ppm, >> vbtkitresources/m3makefile, vbtkitresources/right.ppm, >> vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, >> lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, >> vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, >> lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, >> vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, >> vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: >> >> Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. >> >> >> Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? >> Can the work be redone against the 2008 versions? And factor out the common parts? >> >> I guess I should go and diff these against the 3.6 or 4.1 versions? >> And then apply those diffs to the Posix file to get the Win32 version? >> (Or again, try to share what is the same?) >> >> >> - Jay >> >> > Date: Sun, 13 Dec 2009 04:37:34 +0000 >> > To: m3commit at elegosoft.com >> > From: jkrell at elego.de >> > Subject: [M3commit] CVS Update: cm3 >> > >> > CVSROOT: /usr/cvs >> > Changes by: jkrell at birch. 09/12/13 04:37:34 >> > >> > Modified files: >> > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 >> > m3makefile >> > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 >> > ScrollerVBTClass.m3 >> > >> > Log message: >> > I forgot to mention: I'm really just guessing here. It seems to work. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:19:17 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:19:17 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> Message-ID: <4B262BC8.1E75.00D7.1@scires.com> >>> Olaf Wagner 12/14/2009 6:59 AM >>> >> >> I did notice you made the scrollbars look "nice" on Windows. >> >> The close box is marked "C". >> The grow box is marked "G". >I grant that making it look better would probably increase the user >acceptance. IMO there's no reason not to do that; but there hasn't been >anybody interested in working on it yet. Olaf, it would be easy to factor some of these appearance changes from the Windows-specific code back into the POSIX-specific code. I could do it, but we should first make sure everyone wants this type of behavior. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 18:36:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 17:36:56 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, <4B262A74.1E75.00D7.1@scires.com>, Message-ID: > So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. I did not. How many times I need to say I didn't touch the Posix code? We have posix/scroller and win32/scroller. win32/scroller is a copy/edit of posix/scroller. You can hypothetically compile either on either. It is all portable. To alter the appearance, they are different. In the code that made win32/scroller there was some crashing. I fixed that. To the extent that they are the same, I suggest the two files be merged into one, with "if"s. You know, like, you have approximately three choices in these things. Separate files, #if, and if. But with Modula-3, #if goes away. But you still have "if", depending on what the code looks like. If the branches are wildly divergent, for some definition of "wild", then separate files are appropriate. If the divergence is small, for some definition of "small", then "if" is preferable. Depending on the degree, "if" can be confusing. Too man ifs, hard to read the code fast and see what actually runs. Separate files obviously can lead to redundancy. In fact my first fix was to always use the Posix code. Since it worked and didn't crash. But then I fixed the crash instead. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 19:06:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 13:06:57 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, <4B262A74.1E75.00D7.1@scires.com>, Message-ID: <98166A57-C9AF-40E0-9F91-49AC4AE18ABB@cs.purdue.edu> OK, cool. :-) On 14 Dec 2009, at 12:36, Jay K wrote: > > So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. > > I did not. How many times I need to say I didn't touch the Posix code? > > > We have posix/scroller and win32/scroller. > win32/scroller is a copy/edit of posix/scroller. > You can hypothetically compile either on either. > It is all portable. > To alter the appearance, they are different. > In the code that made win32/scroller there was some crashing. > I fixed that. > > > To the extent that they are the same, I suggest the > two files be merged into one, with "if"s. > You know, like, you have approximately three choices > in these things. > Separate files, #if, and if. > But with Modula-3, #if goes away. > But you still have "if", depending on what the code looks like. > > > If the branches are wildly divergent, for some definition of "wild", > then separate files are appropriate. > If the divergence is small, for some definition of "small", > then "if" is preferable. > > > Depending on the degree, "if" can be confusing. > Too man ifs, hard to read the code fast and see what > actually runs. > Separate files obviously can lead to redundancy. > > > > In fact my first fix was to always use the Posix code. > Since it worked and didn't crash. > But then I fixed the crash instead. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Dec 14 19:12:56 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 14 Dec 2009 10:12:56 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20091214134015.9044F2474001@birch.elegosoft.com>, , , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , , , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu>, , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: <20091214181256.2AEDB1A2078@async.async.caltech.edu> Jay K writes: >--_dcd80a02-fc6b-42d8-93c7-943543066a21_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > >> all DEC systems are little-endian > >Ok=2C educate me. > > VAX little endian?=20 definitely > MIPS-based DecStations running Ultrix little endian?=20 > (again=2C MIPS ran NT=2C but MIPS is "well known" to be "either" there's= yes, definitely > often "mips" and "mipsle"=2C "le"=3D"little endian")=20 > Alpha/VMS little endian?=20 yes > Alpha/Tru64 little endian? =20 yes > IA64/VMS little endian? =20 no idea but I would suspect so > (IA64/HPUX little endian?) no idea > (Alpha/IA64/MIPS/PPC NT yes little all endian)=20 This was one of the things IBM and DEC used to send people out to flame each other over. How each is obviously superior to the other, "wrong-endian" system. This was a while ago.... Mika From peter.mckinna at gmail.com Tue Dec 15 01:27:27 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 15 Dec 2009 11:27:27 +1100 Subject: [M3devel] pickle bug..solved?.. not supposed to work? Message-ID: <3d9e5afc0912141627u2d9d2389k16544f95b815c36a@mail.gmail.com> I also vote for making V2 the default. I think the stubgen code has a hard coded setting making the protocol V1 somewhere. That would have to be fixed as well. Also there is a bunch of imports in various modules of the form Import Pickle2 as Pickle that would have to be changed. Also I have a couple of fixes for the ConvertPacking module for v2 that I should put in to do with 64-32 conversion. I think Blair MacIntyre did a lot of the extension for V2 and you see comments in the code where he has made various changes. I wonder what the etiquette is of removing those comments and leaving a reference to his work in header at the top? Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:01:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:01:55 +0000 Subject: [M3devel] RegisterFinalCleanup and locking? Message-ID: I think RegisterFinalCleanup should be augmented or changed so that caller can use it without holding a lock, thereby avoiding holding two locks (RegisterFinalCleanup uses heap lock) and worrying about the order/deadlock. Some sort of reserve/commit, reserve/cancel system. Like: cleanup := ReserveFinalCleanup(); (* can fail with exception*) cleanup.object := mutex; cleanup.function := CleanMutex; ... CommitFinalCleanup(cleanup); (* cannot fail *) or CancelFinalCleanup(cleanup); (* cannot fail *) I think it might not be at all difficult. Or: cleanup := ReserveFinalCleanup(); (* can fail with exception *) .. CommitFinalCleanup(cleanup, mutex, CleanMutex); or CancelFinalCleanup(cleanup); or: cleanup := ReserveFinalCleanup(mutex, CleanMutex); (* can fail with exception *) and then optional CancelFinalCleanup(cleanup); but not sure the last one is viable. Maybe: UnsafeCollectNow(mutex); ? Hm. Do we have that already? DISPOSE on traced references in unsafe code? And it does or does not handle the registered cleanup? I'll check. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:06:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:06:45 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? Message-ID: Is it possible to initialize mutexes and condition variables right away? Instead of having the delayed initialization? Mutex initialization is pretty fast on Windows, no syscall. Having it be delayed like it is maybe isn't worthwhile. As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? I know there is the idiom NEW(T).init() but that is up to callers to adhere to. Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:17:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:17:27 +0000 Subject: [M3devel] win32 conditionvariables Message-ID: I didn't realize it, but the Java code, now the Modula-3 code is the same as: http://www.cs.wustl.edu/~schmidt/win32-cv-1.html "3.3. The Generation Count Solution" including the downsides he lists -- some unfairness. Now that I notice the similarity, I'll compare against this one as well. And maybe "rewrite" in Modula-3 instead of the current C. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 04:49:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 22:49:48 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: Message-ID: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) On 14 Dec 2009, at 22:06, Jay K wrote: > Is it possible to initialize mutexes and condition variables right away? > Instead of having the delayed initialization? > > > Mutex initialization is pretty fast on Windows, no syscall. > Having it be delayed like it is maybe isn't worthwhile. > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > - Jay > From jay.krell at cornell.edu Tue Dec 15 05:04:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:04:17 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: Is it possible to do on Win32? Win32 critical sections are cheap and already probably work roughly "that way". Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. Our (new) win32 condition variables are not cheap, but similar in cost to Java. (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 22:49:48 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > Is it possible to initialize mutexes and condition variables right away? > > Instead of having the delayed initialization? > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 05:18:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:18:22 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu>, Message-ID: ps: maybe we can hope for the folks under us implementing pthread_mutex and criticalsection to do a very good job? We have much more context?? Inlining?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 15 Dec 2009 04:04:17 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? Is it possible to do on Win32? Win32 critical sections are cheap and already probably work roughly "that way". Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. Our (new) win32 condition variables are not cheap, but similar in cost to Java. (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 22:49:48 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > Is it possible to initialize mutexes and condition variables right away? > > Instead of having the delayed initialization? > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 05:26:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 23:26:43 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: We need an compiler intrinsic CAS to avoid calls. More incentive to get the gcc-based backend working on Windows? I'll bet most modern Java implementations destroy thread libraries on performance. In the uncontended case they have no atomic operations, and the code is all inline. I'm not sure what Java implementation you are looking at... (Hotspot's sucks BTW). On 14 Dec 2009, at 23:04, Jay K wrote: > Is it possible to do on Win32? > Win32 critical sections are cheap and already probably work roughly "that way". > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > - Jay > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > From: hosking at cs.purdue.edu > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > Is it possible to initialize mutexes and condition variables right away? > > > Instead of having the delayed initialization? > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > - Jay > > > > > From hosking at cs.purdue.edu Tue Dec 15 05:39:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 23:39:08 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> So, the basic scenario is as follows. Briefly... We should ditch signals as a mechanism for stopping threads. The compiler should inject a "safe-point" at each procedure call and backward branch. At safe-points, the thread polls a thread-local to see if the run-time system needs it to step out-of-line for some reason. At calls to <*EXTERNAL*> procedures we set a thread-local to say the thread is stepping outside Modula-3 code, with corresponding synchronized test on return in case the run-time needs it to pay attention. Now, when a MUTEX is first acquired, we simply CAS in a bit in the MUTEX along with the acquiring thread's ID. That thread can then release and acquire as often as it likes, no further CAS, no pthread_mutex_lock. Acquirers must always CAS to see if the bit is set. If it is then the lock is reserved for some other thread. We must revoke the reservation by handshake (as described above) with the reserving thread. We then inflate a real pthread_mutex_lock along with any queues needed for the MUTEX/CV. The handshake mechanism can also be used for stopping threads for GC, etc. The point is that uncontended locks should cost almost nothing. On 14 Dec 2009, at 23:04, Jay K wrote: > Is it possible to do on Win32? > Win32 critical sections are cheap and already probably work roughly "that way". > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > - Jay > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > From: hosking at cs.purdue.edu > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > Is it possible to initialize mutexes and condition variables right away? > > > Instead of having the delayed initialization? > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > - Jay > > > > > From jay.krell at cornell.edu Tue Dec 15 05:47:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:47:33 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> , Message-ID: Yes HotSpot. I guess I should look at others and JITed code. C# too. So, question..Java probably has to perf because people probably abuse it. They have to counteract deficiencies elsewhere. Similar for us? Granted, I removed the win32 thread cache. And there was a criticalsection cache in the past. No function call or interlock in uncontended is impressive..you could do that based on the Hotspot code..but is it worth..the inlining bloat and "dependencies" (changes requiring recompiling clients). The gcc backend does work on Windows. In a fashion, a fairly practical fashion. With "mingw" you can just go and configure && make and you get a gcc that doesn't use cygwin. I'm more interested in improving the fast integrated one, or maybe llvm support. Something that writes out .obj files and doesn't require so many processes. Debugging is a mixed story too. Integrated backend outputs only function symbols and line number. Nothing for locals or types. gcc output I believe debuggable only with gdb, at least the cygwin gcc. We can get CAS et. al. without resorting to gcc. As a function call or probably inline. I think that locks in a dependency on newer processors and/or operating systems though. If the integrated backend is missing CAS and that is holding you up, speak up. The integrated backend is just incredibly faster than the gcc backend, both to build and run. - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 23:26:43 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We need an compiler intrinsic CAS to avoid calls. More incentive to get the gcc-based backend working on Windows? > I'll bet most modern Java implementations destroy thread libraries on performance. In the uncontended case they have no atomic operations, and the code is all inline. I'm not sure what Java implementation you are looking at... (Hotspot's sucks BTW). > > On 14 Dec 2009, at 23:04, Jay K wrote: > > > Is it possible to do on Win32? > > Win32 critical sections are cheap and already probably work roughly "that way". > > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > > > - Jay > > > > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > > From: hosking at cs.purdue.edu > > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > > CC: m3devel at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > > > Is it possible to initialize mutexes and condition variables right away? > > > > Instead of having the delayed initialization? > > > > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 06:13:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 05:13:22 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> References: , , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu>, , <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> Message-ID: > That thread can then release and acquire as often as it likes, no further CAS, no > pthread_mutex_lock. Acquirers must always CAS to see if the bit is set How does the thread know it doesn't need to CAS? With a non-atomic check? > polls a thread-local Expensive currently. Can be improved a la gcc __thread, Win32 __declspec(thread), but with limits. __declspec(thread) doesn't work pre-Vista with .dlls loaded "after" the .exe. You can detect that though and switch between two paths. The "reserved" parameter to DllMain tells you if you are loaded in CreateProcess or LoadLibrary, and therefore if __declspec(thread) works pre-Vista or if you need to use TlsAlloc/TlsGetValue. You wouldn't want to inline that though, so "poll a thread local" is a function call. If there are multiple backward branches in a function, you can optimize by remembering the address of the thread local in a "normal" local, certainly. You can also possibly..I haven't thought this through, but I think for each function you can generate two entry points. Call them "internal" and "external". "internal" takes an extra pointer, the pointer to the thread locals. "external" gets the thread locals in an expensive fashion (above) and calls "internal". If a function doesn't actually need the thread locals, the two are aliased to each other. Within a module (a single .m3 file), you always call internal, or maybe within a library/dll, or maybe within Modula-3 entirely. But callbacks or direct calls from C go to external. Though callbacks can do better. Even C calls could do better, if you can break the C/Modula-3 ABI. I'm not sure this overall scheme works out, but I think it does. This is similar to how in some systems exported functions are duplicated. The exported version retrieves the base pointer for the .dll's data and then calls the non-exported one. NT/PPC, NT/IA64, I think Mac/CFM/PPC and others work this way. I believe it helps achieve position independence, all static data is accessed via a register that is maintained for all entry and/or exit from a .dll. > calls to <*EXTERNAL*> procedures Arguably we can do whatever needed in our .c code. You know, since <*external*> is now largely but not completely implemented by us. I realize there's still e.g. X/Windows, OpenGL, Win32. Only "libc" is wrapped aggressively right now, and others are large. And maybe that is all that should be, e.g. OpenGL and Xlib are very portable and so maybe cloning their headers is too? - Jay > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 23:39:08 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > So, the basic scenario is as follows. Briefly... We should ditch signals as a mechanism for stopping threads. The compiler should inject a "safe-point" at each procedure call and backward branch. At safe-points, the thread polls a thread-local to see if the run-time system needs it to step out-of-line for some reason. At calls to <*EXTERNAL*> procedures we set a thread-local to say the thread is stepping outside Modula-3 code, with corresponding synchronized test on return in case the run-time needs it to pay attention. Now, when a MUTEX is first acquired, we simply CAS in a bit in the MUTEX along with the acquiring thread's ID. That thread can then release and acquire as often as it likes, no further CAS, no pthread_mutex_lock. Acquirers must always CAS to see if the bit is set. If it is then the lock is reserved for some other thread. We must revoke the reservation by handshake (as described above) with the reserving thread. We then inflate a real pthread_mutex_lock along with any queues needed for the MUTEX/CV. The handshake mechanism can also be used for stopping threads for GC, etc. > > The point is that uncontended locks should cost almost nothing. > > On 14 Dec 2009, at 23:04, Jay K wrote: > > > Is it possible to do on Win32? > > Win32 critical sections are cheap and already probably work roughly "that way". > > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > > > - Jay > > > > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > > From: hosking at cs.purdue.edu > > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > > CC: m3devel at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > > > Is it possible to initialize mutexes and condition variables right away? > > > > Instead of having the delayed initialization? > > > > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 15 11:42:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Dec 2009 11:42:47 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B262FC7.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> Message-ID: <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > Can you supply me with SRC Report 159 ? > > The link you give doesn't seem to know how to serve up the report. Strange. I had no problem to download it there. I'll CC m3devel in case anybody else cannot get it. Olaf > I would like to better understand the locking level pragmas. > > Regards, > Randy > >>>> Olaf Wagner 12/14/2009 6:59 AM >>> > Quoting Jay K : > >> I keep trying to understand Trestle but I keep failing. >> I tried to read the comments explaining how its locking >> works and I got lost quickly. > > Actually the Trestle locking was `verified' after the implementation > was finished with the Extended Statical Checker written at that time > in Modula-3, too (but reimplemented since then in Java). See > SRC report 159, for example here: > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 > > This is where all the locking level pragmas come from. > >> I suspect that compares well to other GUI libraries >> in that they probably just don't do threading well. > > I always thought that using threads extensively to keep the > application > responding to user request was one of the strong areas of Testle. > >> Easy to understand though. >> >> The Trestle apps are all pretty ugly and oddly behaved. >> Granted, I have no "real use" for them. I just exercise >> them a bit as test cases. >> >> I did notice you made the scrollbars look "nice" on Windows. >> >> The close box is marked "C". >> The grow box is marked "G". > > I grant that making it look better would probably increase the user > acceptance. IMO there's no reason not to do that; but there hasn't > been > anybody interested in working on it yet. > >> Yuck. >> >> As I said though, the more I look into Trestle, the more I think >> it is implementing a rather complete "windows system" and not >> just a library of widgets, nor even widgets + resizing algorithms. >> Nor even just widgets + resizing + event routing. >> >> Like, it seems to also manage clipping, knowing what needs >> redrawing, etc. >> >> But I'm not sure. >> >> It adds up to a lot of code, is my concern. >> >> That is good and bad. > > Yes. But it's a huge project to integrate another GUI library into M3 > and make it as useful as Trestle. > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: SRC-report-159.pdf Type: application/pdf Size: 197231 bytes Desc: not available URL: From hendrik at topoi.pooq.com Tue Dec 15 15:08:46 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Dec 2009 09:08:46 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> Message-ID: <20091215140846.GA12996@topoi.pooq.com> On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: > So, the basic scenario is as follows. Briefly... We should ditch > signals as a mechanism for stopping threads. The compiler should > inject a "safe-point" at each procedure call and backward branch. At > safe-points, the thread polls a thread-local to see if the run-time > system needs it to step out-of-line for some reason. ... ... > > The point is that uncontended locks should cost almost nothing. Nothing? All those safe-points cost time, don't they, even when no locks are being used at all? Is this analogous to charging everyone for the overhead involved in recursion, even when no recursion is being used? -- hendrik From mika at async.async.caltech.edu Tue Dec 15 16:02:14 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 15 Dec 2009 07:02:14 -0800 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215140846.GA12996@topoi.pooq.com> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> Message-ID: <20091215150214.D4E8D1A207A@async.async.caltech.edu> What's the main problem you guys are trying to solve? In my experience the biggest performance loss in moving from PM3 user threads to CM3 pthreads has been with programs that lock a lot but are actually not using the thread-safety for anything. Those programs would be improved greatly by a scheme such as the one Tony describes, where a mutex is "passed" between the threads, with "real locking" only when it has to be passed from one locker to another, not when a single locker locks and re-locks the mutex. But I don't see how that implies a need to change the thread-stopping mechanism.... it's something else, I take it? Mika hendrik at topoi.pooq.com writes: >On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >> So, the basic scenario is as follows. Briefly... We should ditch >> signals as a mechanism for stopping threads. The compiler should >> inject a "safe-point" at each procedure call and backward branch. At >> safe-points, the thread polls a thread-local to see if the run-time >> system needs it to step out-of-line for some reason. > >... >... >> >> The point is that uncontended locks should cost almost nothing. > >Nothing? All those safe-points cost time, don't they, even when no >locks are being used at all? > >Is this analogous to charging everyone for the overhead involved in >recursion, even when no recursion is being used? > >-- hendrik From hosking at cs.purdue.edu Tue Dec 15 16:18:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 10:18:17 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215140846.GA12996@topoi.pooq.com> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> Message-ID: Yes, good point. It really is a question of how much does the safe-point check cost. Perhaps for a "systems" language like Modula-3 it is important that we not tax code that doesn't use threads or locks. But in today's world code like that is less common, no? And Modula-3 positively encourages them. On the other hand, Modula-3 demands programmers explicitly declare their locks (unlike Java which says any object can be a lock or CV), so perhaps retaining the referential transparency of explicit locks (you don't pay unless you use them) is more in the Modula-3 "systems" programming way of thinking. There are other ways to do the safe-points. One could "poison" (access-protect) a page that the thread simply reads a location from at the safe-points, whereupon it will trap. But in some experiments we have done with Java, it is more important that the thread simply ack, rather than having actually to take a trap and come to a screeching halt in a signal handler. And, since most threads are usually blocked or executing some external system call, you don't even have to wait for the ack. On 15 Dec 2009, at 09:08, hendrik at topoi.pooq.com wrote: > On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >> So, the basic scenario is as follows. Briefly... We should ditch >> signals as a mechanism for stopping threads. The compiler should >> inject a "safe-point" at each procedure call and backward branch. At >> safe-points, the thread polls a thread-local to see if the run-time >> system needs it to step out-of-line for some reason. > > ... > ... >> >> The point is that uncontended locks should cost almost nothing. > > Nothing? All those safe-points cost time, don't they, even when no > locks are being used at all? > > Is this analogous to charging everyone for the overhead involved in > recursion, even when no recursion is being used? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 16:24:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 10:24:48 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215150214.D4E8D1A207A@async.async.caltech.edu> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> <20091215150214.D4E8D1A207A@async.async.caltech.edu> Message-ID: On 15 Dec 2009, at 10:02, Mika Nystrom wrote: > What's the main problem you guys are trying to solve? > > In my experience the biggest performance loss in moving from PM3 user > threads to CM3 pthreads has been with programs that lock a lot but are > actually not using the thread-safety for anything. Exactly. In "uniprocessor" user-threading, lock is simply INC(inCritical)/DEC(inCritical), which controls whether threads can switch or not. > Those programs would be improved greatly by a scheme such as the one > Tony describes, where a mutex is "passed" between the threads, with > "real locking" only when it has to be passed from one locker to another, > not when a single locker locks and re-locks the mutex. > > But I don't see how that implies a need to change the thread-stopping > mechanism.... it's something else, I take it? We could use a CAS on every acquire/release, implementing the Thin Locks technique mentioned in one of the papers I cited. I wanted to go one step more, to avoid the CAS (which has overhead beyond a simple load/store) by allowing a lock to be reserved to one thread the first time it is acquired. That thread gets to acquire/release without CAS. When another thread comes along and wants the lock it needs a mechanism to revoke the reservation. That's why we need the handshake mechanism. I could use the current signal-based approach, but that has the nasty effect of stopping the target thread in its tracks. Better that it simply ack the revocation and then keep running. > Mika > > hendrik at topoi.pooq.com writes: >> On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >>> So, the basic scenario is as follows. Briefly... We should ditch >>> signals as a mechanism for stopping threads. The compiler should >>> inject a "safe-point" at each procedure call and backward branch. At >>> safe-points, the thread polls a thread-local to see if the run-time >>> system needs it to step out-of-line for some reason. >> >> ... >> ... >>> >>> The point is that uncontended locks should cost almost nothing. >> >> Nothing? All those safe-points cost time, don't they, even when no >> locks are being used at all? >> >> Is this analogous to charging everyone for the overhead involved in >> recursion, even when no recursion is being used? >> >> -- hendrik From rodney_bates at lcwb.coop Tue Dec 15 22:23:50 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 15 Dec 2009 15:23:50 -0600 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> Message-ID: <4B27FE66.5010600@lcwb.coop> Olaf Wagner wrote: > Quoting Randy Coleburn : > >> Olaf: >> >> Can you supply me with SRC Report 159 ? >> >> The link you give doesn't seem to know how to serve up the report. I got some kind of permission failure when trying to get it via http: http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-159.ps.gz I manually edited the 'http' to 'ftp' and got it without trouble. I could also use ftp to see a listing of the parent directory, with all the SRC reports. > > Strange. I had no problem to download it there. > I'll CC m3devel in case anybody else cannot get it. > > Olaf > >> I would like to better understand the locking level pragmas. >> >> Regards, >> Randy >> >>>>> Olaf Wagner 12/14/2009 6:59 AM >>> >> Quoting Jay K : >> >>> I keep trying to understand Trestle but I keep failing. >>> I tried to read the comments explaining how its locking >>> works and I got lost quickly. >> >> Actually the Trestle locking was `verified' after the implementation >> was finished with the Extended Statical Checker written at that time >> in Modula-3, too (but reimplemented since then in Java). See >> SRC report 159, for example here: >> >> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 >> >> This is where all the locking level pragmas come from. >> >>> I suspect that compares well to other GUI libraries >>> in that they probably just don't do threading well. >> >> I always thought that using threads extensively to keep the >> application >> responding to user request was one of the strong areas of Testle. >> >>> Easy to understand though. >>> >>> The Trestle apps are all pretty ugly and oddly behaved. >>> Granted, I have no "real use" for them. I just exercise >>> them a bit as test cases. >>> >>> I did notice you made the scrollbars look "nice" on Windows. >>> >>> The close box is marked "C". >>> The grow box is marked "G". >> >> I grant that making it look better would probably increase the user >> acceptance. IMO there's no reason not to do that; but there hasn't >> been >> anybody interested in working on it yet. >> >>> Yuck. >>> >>> As I said though, the more I look into Trestle, the more I think >>> it is implementing a rather complete "windows system" and not >>> just a library of widgets, nor even widgets + resizing algorithms. >>> Nor even just widgets + resizing + event routing. >>> >>> Like, it seems to also manage clipping, knowing what needs >>> redrawing, etc. >>> >>> But I'm not sure. >>> >>> It adds up to a lot of code, is my concern. >>> >>> That is good and bad. >> >> Yes. But it's a huge project to integrate another GUI library into M3 >> and make it as useful as Trestle. >> >> Olaf From peter.mckinna at gmail.com Wed Dec 16 02:13:30 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Wed, 16 Dec 2009 12:13:30 +1100 Subject: [M3devel] Hard real time Message-ID: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Hi, Is there any way to use the realtime options of pthreads, to set the scheduler and the mutex protocols for priority inherit etc, all that good stuff in an M3 program? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 02:18:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 20:18:53 -0500 Subject: [M3devel] Hard real time In-Reply-To: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Message-ID: <785B08D1-2A2E-4202-8D67-132C6D0E21A7@cs.purdue.edu> It would be possible if we supported APIs for that. On 15 Dec 2009, at 20:13, Peter McKinna wrote: > Hi, > > Is there any way to use the realtime options of pthreads, to set the scheduler and the mutex protocols for priority inherit etc, all that good stuff in an M3 program? > > Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 16 10:35:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 10:35:35 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B27FE66.5010600@lcwb.coop> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> <4B27FE66.5010600@lcwb.coop> Message-ID: <20091216103535.ufbvdqddb0gwgc08@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Olaf Wagner wrote: >> Quoting Randy Coleburn : >> >>> Olaf: >>> >>> Can you supply me with SRC Report 159 ? >>> >>> The link you give doesn't seem to know how to serve up the report. > I got some kind of permission failure when trying to get it via http: > > http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-159.ps.gz > > I manually edited the 'http' to 'ftp' and got it without trouble. I could > also use ftp to see a listing of the parent directory, with all the SRC > reports. So gatekeeper is still online :-) I wonder if I should ask Greg Nelson if we could get the M3 code for ESC... but it's probably not going to be(come) open source, as it has been ported to Java since and may well be commercially used. It would be great if we had such a tool for CM3 though. 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 From wagner at elegosoft.com Wed Dec 16 10:39:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 10:39:06 +0100 Subject: [M3devel] Hard real time In-Reply-To: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Message-ID: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Quoting Peter McKinna : > Hi, > > Is there any way to use the realtime options of pthreads, to set the > scheduler and the mutex protocols for priority inherit etc, all that good > stuff in an M3 program? I don't know of such an interface, but it would be great if we had it. Is this stuff pthread standard, or more or less system dependent? 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 From jay.krell at cornell.edu Wed Dec 16 11:35:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 10:35:42 +0000 Subject: [M3devel] Hard real time In-Reply-To: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com>, <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Message-ID: search the web for: "setthreadpriority" "opengroup sched.h" http://www.opengroup.org/onlinepubs/007908799/xsh/sched.h.html http://msdn.microsoft.com/en-us/library/ms686277(VS.85).aspx etc. Would be good to abstract out something that can be done over pthreads and Win32 and possibly user threads. As I understand, "hard real time" is rare. You know, when page faults occur cannot be unpredictable and still be hard real time, right? "rough scheduling parameters", sure, but not "hard real time". You could also ignore Win32 and user threads and drop down into C and party on pthread_self(). That is, the key is coming up with portable interfaces and interface "policing". - Jay > Date: Wed, 16 Dec 2009 10:39:06 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hard real time > > Quoting Peter McKinna : > > > Hi, > > > > Is there any way to use the realtime options of pthreads, to set the > > scheduler and the mutex protocols for priority inherit etc, all that good > > stuff in an M3 program? > > I don't know of such an interface, but it would be great if we had > it. Is this stuff pthread standard, or more or less system dependent? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 11:39:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 10:39:34 +0000 Subject: [M3devel] Hard real time In-Reply-To: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com>, <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Message-ID: (We should port to QNX and VxWorks?) :) - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] Hard real time Date: Wed, 16 Dec 2009 10:35:42 +0000 search the web for: "setthreadpriority" "opengroup sched.h" http://www.opengroup.org/onlinepubs/007908799/xsh/sched.h.html http://msdn.microsoft.com/en-us/library/ms686277(VS.85).aspx etc. Would be good to abstract out something that can be done over pthreads and Win32 and possibly user threads. As I understand, "hard real time" is rare. You know, when page faults occur cannot be unpredictable and still be hard real time, right? "rough scheduling parameters", sure, but not "hard real time". You could also ignore Win32 and user threads and drop down into C and party on pthread_self(). That is, the key is coming up with portable interfaces and interface "policing". - Jay > Date: Wed, 16 Dec 2009 10:39:06 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hard real time > > Quoting Peter McKinna : > > > Hi, > > > > Is there any way to use the realtime options of pthreads, to set the > > scheduler and the mutex protocols for priority inherit etc, all that good > > stuff in an M3 program? > > I don't know of such an interface, but it would be great if we had > it. Is this stuff pthread standard, or more or less system dependent? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 13:37:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 12:37:38 +0000 Subject: [M3devel] providing "bootstrap" archives Message-ID: jay at xlin2:/dev2/cm3/scripts/python$ ls -l *gz -rw-r--r-- 1 jay jay 5002815 2009-12-16 04:15 cm3-boot-AMD64_FREEBSD-1.tar.gz -rw-r--r-- 1 jay jay 5004281 2009-12-16 04:30 cm3-boot-AMD64_OPENBSD-1.tar.gz -rw-r--r-- 1 jay jay 5225719 2009-12-16 03:45 cm3-boot-I386_DARWIN-1.tar.gz -rw-r--r-- 1 jay jay 4471845 2009-12-16 03:59 cm3-boot-I386_OPENBSD-1.tar.gz -rw-r--r-- 1 jay jay 5356193 2009-12-16 03:29 cm3-boot-PPC_DARWIN-1.tar.gz -rw-r--r-- 1 jay jay 5506665 2009-12-16 03:29 cm3-boot-PPC_LINUX-1.tar.gz -rw-r--r-- 1 jay jay 4871443 2009-12-16 03:05 cm3-boot-SPARC32_LINUX-1.tar.gz jay at xlin2:/dev2/cm3/scripts/python$ cat 1.sh for a in PPC_LINUX PPC_DARWIN I386_DARWIN I386_OPENBSD AMD64_FREEBSD \ AMD64_OPENBSD AMD64_LINUX AMD64_DARWIN SOLsun SOLgnu \ SPARC64_OPENBSD SPARC32_LINUX SPARC64_SOLARIS MIPS64_OPENBSD; do ./boot1.py $a done Possibly we should be running that in Hudson or something, on one or more machines? I believe there's one problem running it on 64 bit hosts. I'll fix that soon. These archives, copied to the target machine that contains cc/make/ld, possibly with a little bit of Makefile editing, can build cm3. And then from there you can build everything else. A bunch of cm3cg result too that maybe should be distributed somehow/somewhere. Probably "-1" should be changed to a real version/date. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 16 13:57:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 13:57:20 +0100 Subject: [M3devel] providing "bootstrap" archives In-Reply-To: References: Message-ID: <20091216135720.a5b46rhbzq8o400c@mail.elegosoft.com> Quoting Jay K : > > jay at xlin2:/dev2/cm3/scripts/python$ ls -l *gz > -rw-r--r-- 1 jay jay 5002815 2009-12-16 04:15 cm3-boot-AMD64_FREEBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5004281 2009-12-16 04:30 cm3-boot-AMD64_OPENBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5225719 2009-12-16 03:45 cm3-boot-I386_DARWIN-1.tar.gz > -rw-r--r-- 1 jay jay 4471845 2009-12-16 03:59 cm3-boot-I386_OPENBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5356193 2009-12-16 03:29 cm3-boot-PPC_DARWIN-1.tar.gz > -rw-r--r-- 1 jay jay 5506665 2009-12-16 03:29 cm3-boot-PPC_LINUX-1.tar.gz > -rw-r--r-- 1 jay jay 4871443 2009-12-16 03:05 cm3-boot-SPARC32_LINUX-1.tar.gz > > > jay at xlin2:/dev2/cm3/scripts/python$ cat 1.sh > for a in PPC_LINUX PPC_DARWIN I386_DARWIN I386_OPENBSD AMD64_FREEBSD \ > AMD64_OPENBSD AMD64_LINUX AMD64_DARWIN SOLsun SOLgnu \ > SPARC64_OPENBSD SPARC32_LINUX SPARC64_SOLARIS MIPS64_OPENBSD; do > ./boot1.py $a > done > > Possibly we should be running that in Hudson or something, on one or > more machines? Great! We should definitely add that to the Hudson jobs. I'm far behind there and hope to be able to do something during the Christmas break. It would be great if we could finish the release though and use the Hudson jobs for the trunk. There are not enough resources currently to do both, at least not on my or Elego's systems. Olaf > I believe there's one problem running it on 64 bit hosts. > > I'll fix that soon. > > These archives, copied to the target machine that contains > cc/make/ld, possibly > > with a little bit of Makefile editing, can build cm3. > > And then from there you can build everything else. > > > > > > A bunch of cm3cg result too that maybe should be distributed > somehow/somewhere. > > > > > > Probably "-1" should be changed to a real version/date. > > > > - Jay > -- 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 From jay.krell at cornell.edu Wed Dec 16 14:05:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 13:05:38 +0000 Subject: [M3devel] email hiccup Message-ID: Mail to me will see bounces but it does get through. I'm working on it. (see -- it gets forwarded to two places, one that I read, and one that is bouncing..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 16:36:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 15:36:24 +0000 Subject: [M3devel] pthread/Interix Message-ID: [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 16:40:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 15:40:04 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: References: Message-ID: (verified that empty records are of zero size; in C++ that's a not always possible optimization, they often have a filler byte, in order to generate unique addresses in places.) From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Wed, 16 Dec 2009 15:36:24 +0000 Subject: [M3devel] pthread/Interix [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 17:40:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 11:40:56 -0500 Subject: [M3devel] pthread/Interix In-Reply-To: References: Message-ID: <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote: > [again, expect a bounce, but the mail does get through] > > > Tony, for Interix, suspend/resume thread can be achieved writing to a file. > Getting a suspended thread's registers can be gotten reading from a file. > (I believe the same thing works on Solaris.) > It appears to be intended for debuggers. > I can see that it works well. > I doubt that a thread's context is on a signal handler's stack. > I propose: > > > ActState = { Starting, Started, Stopping, Stopped }; > REVEAL Activation = UNTRACED BRANDED REF RECORD > frame: ADDRESS := NIL; (* exception handling support *) > handle: pthread_t := NIL; (* LL = activeMu; thread handle *) > statusFile: int := -1; (* for Interix *) > controlFile: int := -1; (* for Interix *) > (* C code knows the structure above this point *) > ... > END; > > > ThreadPThread.h: > > > typedef struct _Activation_t { > void* frame; > void* pthread; > int statusFile; /* for Interix */ > int controlFile; /* for Interix */ > } Activation_t; > > > and then whereever we pass act.handle off to C code, pass act instead. > > > frame is kept first so that it is offset 0 in case that gives codegen efficiencies > on the often used push/popframe. > The other three are moved up to the top to reduce maintainence of ThreadPThread.h. > > > I assume "branding" doesn't introduce data in the record. > I'd have to check the codegen to verify frame is at offset 0. > > > #ifdef code will open the files. > Modula-3 code can check if the files are >= 0 and close them, > or it can be a call out to #ifdefed C. > > > An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. > (as VAR for initialization). > That is less fragile and less extensible. > I'm fine with that approach too. > > > As well though, I was wondering, maybe we should have: > > > common/InterixThreadState.i3 > T = RECORD END; (* zero size? *) > > > interix/InterixThreadState.i3 > T = RECORD statusFile, controlFile := -1; END; > > > and then put InterixThreadState.T in Activation. > That way saving the other platforms from spending the space. > Just two integers, not much, but in principle.. > (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, > on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) > > > I could also open/close the files for every suspend/resume/processStopped, > though that seems too lame. > > > Another idea, that I don't really like, is to never optimize and > ignore the registers and just use the stack. > I rarely optimize, but depending on that seems bad. > > > Your "safe points" proposal would also make this work, though > I'd rather not wait for that. > > > ? > > Ok to add the two integers all the time? > Ok to either depend on the record layout in C, or to always pass the integers around? > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 17:49:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 16:49:52 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> Message-ID: Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. There is only single parameter signal handlers. Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. That is what is particularly unfortunate. I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 11:40:56 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote: [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 18:08:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 12:08:09 -0500 Subject: [M3devel] pthread/Interix In-Reply-To: References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> Message-ID: <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> On 16 Dec 2009, at 11:49, Jay K wrote: > Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. Interesting, this is exactly the way Mach does signals (which is why we use the Mach suspend/resume primitives for Darwin/OSX). If that is how they work, then can't you use the suspend/resume primitives directly? > There is only single parameter signal handlers. > > Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. > That is what is particularly unfortunate. > > I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. > > An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. > > (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) > > - Jay > > > Subject: Re: pthread/Interix > From: hosking at cs.purdue.edu > Date: Wed, 16 Dec 2009 11:40:56 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I really dislike this... just for a broken platform... > > Is there really no way to know that the context on is not on the stack somewhere? > > On 16 Dec 2009, at 10:36, Jay K wrote: > > [again, expect a bounce, but the mail does get through] > > > Tony, for Interix, suspend/resume thread can be achieved writing to a file. > Getting a suspended thread's registers can be gotten reading from a file. > (I believe the same thing works on Solaris.) > It appears to be intended for debuggers. > I can see that it works well. > I doubt that a thread's context is on a signal handler's stack. > I propose: > > > ActState = { Starting, Started, Stopping, Stopped }; > REVEAL Activation = UNTRACED BRANDED REF RECORD > frame: ADDRESS := NIL; (* exception handling support *) > handle: pthread_t := NIL; (* LL = activeMu; thread handle *) > statusFile: int := -1; (* for Interix *) > controlFile: int := -1; (* for Interix *) > (* C code knows the structure above this point *) > ... > END; > > > ThreadPThread.h: > > > typedef struct _Activation_t { > void* frame; > void* pthread; > int statusFile; /* for Interix */ > int controlFile; /* for Interix */ > } Activation_t; > > > and then whereever we pass act.handle off to C code, pass act instead. > > > frame is kept first so that it is offset 0 in case that gives codegen efficiencies > on the often used push/popframe. > The other three are moved up to the top to reduce maintainence of ThreadPThread.h. > > > I assume "branding" doesn't introduce data in the record. > I'd have to check the codegen to verify frame is at offset 0. > > > #ifdef code will open the files. > Modula-3 code can check if the files are >= 0 and close them, > or it can be a call out to #ifdefed C. > > > An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. > (as VAR for initialization). > That is less fragile and less extensible. > I'm fine with that approach too. > > > As well though, I was wondering, maybe we should have: > > > common/InterixThreadState.i3 > T = RECORD END; (* zero size? *) > > > interix/InterixThreadState.i3 > T = RECORD statusFile, controlFile := -1; END; > > > and then put InterixThreadState.T in Activation. > That way saving the other platforms from spending the space. > Just two integers, not much, but in principle.. > (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, > on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) > > > I could also open/close the files for every suspend/resume/processStopped, > though that seems too lame. > > > Another idea, that I don't really like, is to never optimize and > ignore the registers and just use the stack. > I rarely optimize, but depending on that seems bad. > > > Your "safe points" proposal would also make this work, though > I'd rather not wait for that. > > > ? > > Ok to add the two integers all the time? > Ok to either depend on the record layout in C, or to always pass the integers around? > > > Thanks, > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 18:40:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 17:40:52 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> , <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> Message-ID: There are no public suspend/resume primitives exposed. You can see in the debugger what happens. The signal handling thread calls NtSuspendThread/NtResumeThread. I suppose there is a chance they use the target thread's stack to hold the full previous context, I can dig in the debugger and see. I don't think what I have is too awful though. You see the test_interix.c file? I believe Cygwin does similar, though in that case the thread probably doesn't have the constrained access and you can use the public Win32 GetCurrentThread/DuplicateHandle/SuspendThread/ResumeThread functions. Remember how I had that turning of pthread_self into GetThreadForThis, GetThreadForThat? e.g. one is pthread_self, the other is GetCurrentThread/DuplicateHandle. That might come back. - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 12:08:09 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 16 Dec 2009, at 11:49, Jay K wrote:Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. Interesting, this is exactly the way Mach does signals (which is why we use the Mach suspend/resume primitives for Darwin/OSX). If that is how they work, then can't you use the suspend/resume primitives directly? There is only single parameter signal handlers. Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. That is what is particularly unfortunate. I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 11:40:56 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote:[again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Wed Dec 16 21:48:02 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 16 Dec 2009 12:48:02 -0800 (PST) Subject: [M3devel] Oops, forgot to ask Message-ID: <351872.44455.qm@web56806.mail.re3.yahoo.com> Hi Gang, 0 - CARDINALs are an integral type defined by the language spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, a change was made to CM3 to extend the language it recognizes beyond the original language spec (SPWM3), now CM3 understands a LONGINT. Was there a corresponding LONGCARD defined? Can is use all 64-bits, or is it restricted to 63, like the CARDINAL is only 31-bits. 1 - How does one write a WIDECHAR literal? Are WIDECHAR currently only 16-bits? If so they are limited to only the basic multilingual plane (BMP). Unicode characters are 20-bits, which is why encodings such as USC-32 exist. If a WIDECHAR is only 16-bits, are they encoded as UTF-16, which is a similar scheme to UTF-8? If they are currently only 16-bits, are there plans to expand it to fully support unicode character encodings? 2 - Recently there was discussion about creating a new type, that is halfway a REFANY, and halfway a value itself. I myself dislike unions, and fortran equivalences, and any other aliasing techniques, but if the compiler supports it, we should document it. What was it finally called? How does one declare an item of this type? How does one use it? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Wed Dec 16 22:31:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 16:31:00 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > Hi Gang, > > 0 - CARDINALs are an integral type defined by the language > spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > a change was made to CM3 to extend the language it recognizes > beyond the original language spec (SPWM3), now CM3 understands > a LONGINT. > > Was there a corresponding LONGCARD defined? No. But you can write: [0L..LAST(LONGINT)] just as CARDINAL=[0..LAST(INTEGER)] > Can is use all 64-bits, or is it restricted to 63, like > the CARDINAL is only 31-bits. 63 bits, since its underlying base type is LONGINT. > 1 - How does one write a WIDECHAR literal? Are WIDECHAR > currently only 16-bits? If so they are limited to only > the basic multilingual plane (BMP). Unicode characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are currently > only 16-bits, are there plans to expand it to fully support > unicode character encodings? I don't know... ? Probably should. > 2 - Recently there was discussion about creating a new type, > that is halfway a REFANY, and halfway a value itself. I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > we should document it. > > What was it finally called? > How does one declare an item of this type? > How does one use it? There is no new type like this. But, there is provision in the current implementation of the run-time system to ignore any reference value that has a low-bit set. The only way to use it is to LOOPHOLE values with low-bit set into REFANY. TYPECODE(r) for such tagged values returns what would be TYPECODE(REFANY) (but that expression is a compile-time error to write). So, anyone wanting to compare the typecode must use RT0.RefanyTypecode. The implications of all of this are that tagged REFANYs are implementation-dependent, and can only be used with the unsafe LOOPHOLE. In other words, it is not part of the language definition. And, the implementation may not support it in future... > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From dabenavidesd at yahoo.es Wed Dec 16 22:47:41 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Dec 2009 21:47:41 +0000 (GMT) Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <189565.77906.qm@web23601.mail.ird.yahoo.com> Hi Peter and all: I know think MAX(CARDINAL) should be of value 2^31 - 1 in 32 bits platforms.. There is no LONGCARD. If you want to perform unsigned arithmetic operations you can use WORD an you will have 2^32 values or 2^64 in 32 and 64 bits platform correspondent. Concerning INTEGER historically has been 32 bits in 32 bits word size platforms and (by now) 64 bits in 64 bits platforms. LONGINT is tought to be 64 bit in supported platforms (NT386 integrated backend doesn't have it yet). So that Another note about historical type changes I could add is that Math interface to C native library its function return types were once REAL but now are LONGREAL. You can convert LONGREAL to REAL values doing FLOAT(Math.Degree, REAL) for code expecting REAL values; I know WIDECHAR is an additional representation of TEXT in such a case you want to pop WIDECHAR values you will get it from Text interface, all supported platforms have it, I guess the intended use is related to interface native C types and besides the UTF-8 Java Virtual Machine standard internal codification (Modula-3 doesn't enforce that, so there could be an implementation with such encoding I think, said that, so far now, CM3 is not UTF-8 coded as I know) What I understood about having BRANDED REF is to allow C (calloc) capability of having REF values dynamically allocated in stack memory, allowing speed up in programs that use that (calloc C correspondent). I don't about how does affect type system tough, I mean following Modula-3 BRANDED OBJECT type objects have nominal type equivalence (different from default structural type equivalence) it should be the same for BRANDED REF I think thats all I know for know, hope it helps --- El mi?, 16/12/09, Peter Eiserloh escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Oops, forgot to ask > Para: "M3Devel" > Fecha: mi?rcoles, 16 de diciembre, 2009 15:48 > Hi Gang, > > 0 - CARDINALs are an integral type defined by the language > spec to be from 0 (zero) to MAXINT (not MAXCARD). > Recently, > a change was made to CM3 to extend the language it > recognizes > beyond the original language spec (SPWM3), now CM3 > understands > a LONGINT. > > Was there a corresponding LONGCARD defined? > Can is use all 64-bits, or is it restricted to 63, like > the CARDINAL is only 31-bits. > > > 1 - How does one write a WIDECHAR literal? Are > WIDECHAR > currently only 16-bits? If so they are limited to > only > the basic multilingual plane (BMP). Unicode > characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are > currently > only 16-bits, are there plans to expand it to fully support > > unicode character encodings? > > > 2 - Recently there was discussion about creating a new > type, > that is halfway a REFANY, and halfway a value itself. > I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > > we should document it. > > What was it finally called? > How does one declare an item of this type? > How does one use it? > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > > | > +--------------------------------------------------------+ > > > > From rodney_bates at lcwb.coop Wed Dec 16 23:56:55 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2009 16:56:55 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> Message-ID: <4B2965B7.6040304@lcwb.coop> Tony Hosking wrote: > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > >> Hi Gang, >> >> 0 - CARDINALs are an integral type defined by the language >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, >> a change was made to CM3 to extend the language it recognizes >> beyond the original language spec (SPWM3), now CM3 understands >> a LONGINT. >> >> Was there a corresponding LONGCARD defined? >> > > No. But you can write: > > [0L..LAST(LONGINT)] > > just as > > CARDINAL=[0..LAST(INTEGER)] > Actually, the line above was once true, long long ago, when dinosaurs roamed unfettered. CARDINAL was changed to be "just like" (but not equal to) [0..LAST(INTEGER)]. This would have been maybe early 1990s. It took me years to figure out what this actually meant, and more years to figure out why, but I believe I now know. CARDINAL is not an equal type to [0..LAST(INTEGER)], but otherwise has all the same properties. This makes the two mutually assignable, which is close enough to equal to not matter in most contexts. The exact consequences follow from other language rules. The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of machines with different values of LAST(INTEGER)), because the numeric value of LAST(INTEGER) is part of the expanded type. The one place this matters is if you use pickles to transfer data between machines of different word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash of the complete, expanded type definition) is different on the two machines, and values of or containing this type cannot be transferred. Exact type signature matches are used in pickles to find corresponding types when reading. But pickles handle different sized INTEGER values fine, expanding/shortening as needed. Being a leaf in a type definition, INTEGER is always the same type on any machine. So CARDINAL was changed to be its own unique type too, so it would be possible also to transfer CARDINAL values in pickles between different word sizes. So, we really should have a LONGCARD, parallel to CARDINAL. Note that this also affects network objects, which use pickles to transfer values of the objects. > > >> Can is use all 64-bits, or is it restricted to 63, like >> the CARDINAL is only 31-bits. >> > > 63 bits, since its underlying base type is LONGINT. > > > >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> >> > > > From hendrik at topoi.pooq.com Thu Dec 17 00:13:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Dec 2009 18:13:49 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <20091216231349.GB15089@topoi.pooq.com> On Wed, Dec 16, 2009 at 12:48:02PM -0800, Peter Eiserloh wrote: > > 2 - Recently there was discussion about creating a new type, > that is halfway a REFANY, and halfway a value itself. I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > we should document it. I too hate C unions and fortran equivalences. They cause program breakage, because they're violently insecure. But that's not that these are. These things are properly type-tagged, and if further it is impossible to get at their contents without checking the proper type-tag. -- hendrik From rodney_bates at lcwb.coop Thu Dec 17 00:35:29 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2009 17:35:29 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <4B296EC1.1080407@lcwb.coop> Peter Eiserloh wrote: > Hi Gang, > > > > 1 - How does one write a WIDECHAR literal? Are WIDECHAR > currently only 16-bits? If so they are limited to only > the basic multilingual plane (BMP). Put a 'W' or 'w' immediately before the opening single quote of a character literal, and it becomes a WIDECHAR literal. It has type WIDECHAR, allows characters with 16-bit codes, and also allows 16-bit octal and hex escapes. You can do the same with TEXT literals, but there is no such thing as "WIDETEXT". There is only one type TEXT and it can contain any characters in the 16-bit range. The internal representation has many options, dynamically chosen, and part or all of the value may be represented using only 8 bits per character, if the character values permit. Normally, this is all hidden. > Unicode characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are currently > only 16-bits, are there plans to expand it to fully support > unicode character encodings? > There have been some heated wars in this list over how to represent characters in the 16- and 20- bit ranges, with no consensus, that I saw. It is confused by the fact that you can easily put different representations into the same data type, without language changes. I tend to favor fixed-size representations for in-memory program variables, to preserve constant-time subscripted access. But the variable sized representations appear to allow certain common cases to be handled by unmodified source code, written originally for only 8-bit characters. > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From jay.krell at cornell.edu Thu Dec 17 01:52:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Dec 2009 00:52:06 +0000 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2965B7.6040304@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, <4B2965B7.6040304@lcwb.coop> Message-ID: "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. (Actually it would have been useful long ago.) I really think "long" is a dumb name.. There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. - Jay > Date: Wed, 16 Dec 2009 16:56:55 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Oops, forgot to ask > > Tony Hosking wrote: > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > >> Hi Gang, > >> > >> 0 - CARDINALs are an integral type defined by the language > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > >> a change was made to CM3 to extend the language it recognizes > >> beyond the original language spec (SPWM3), now CM3 understands > >> a LONGINT. > >> > >> Was there a corresponding LONGCARD defined? > >> > > > > No. But you can write: > > > > [0L..LAST(LONGINT)] > > > > just as > > > > CARDINAL=[0..LAST(INTEGER)] > > > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in > pickles > between different word sizes. > > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > >> the CARDINAL is only 31-bits. > >> > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > >> > >> > >> > >> +--------------------------------------------------------+ > >> | Peter P. Eiserloh | > >> +--------------------------------------------------------+ > >> > >> > >> > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 17 02:06:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 20:06:52 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2965B7.6040304@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> Message-ID: <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> This does not make sense: Here is the compiler's definition of the builtin CARDINAL type: MODULE Card; IMPORT SubrangeType, Target, TInt, Tipe, Int; PROCEDURE Initialize () = BEGIN T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); Tipe.Define ("CARDINAL", T, TRUE); END Initialize; BEGIN END Card. Notice that it is a subrange type [0..LAST(INTEGER)]. 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 16 Dec 2009, at 17:56, Rodney M. Bates wrote: > Tony Hosking wrote: >> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: >> >> >>> Hi Gang, >>> >>> 0 - CARDINALs are an integral type defined by the language >>> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, >>> a change was made to CM3 to extend the language it recognizes >>> beyond the original language spec (SPWM3), now CM3 understands >>> a LONGINT. >>> Was there a corresponding LONGCARD defined? >>> >> >> No. But you can write: >> >> [0L..LAST(LONGINT)] >> >> just as >> >> CARDINAL=[0..LAST(INTEGER)] >> > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in pickles > between different word sizes. > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > >> >> >>> Can is use all 64-bits, or is it restricted to 63, like >>> the CARDINAL is only 31-bits. >>> >> >> 63 bits, since its underlying base type is LONGINT. >> >> >> >>> >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> >>> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 17 02:10:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 20:10:14 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, <4B2965B7.6040304@lcwb.coop> Message-ID: On 16 Dec 2009, at 19:52, Jay K wrote: > "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? > > > See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. > (Actually it would have been useful long ago.) LONGINT could be 128 bits for all its definition cares. It is just something usually (not always) bigger than an INTEGER. > I really think "long" is a dumb name.. > There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. Now these are dumb names because they wire in the size of the value. In Modula-3 INTEGER is a natural (i.e., word-size) value. > > > - Jay > > > > Date: Wed, 16 Dec 2009 16:56:55 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Oops, forgot to ask > > > > Tony Hosking wrote: > > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > > > > >> Hi Gang, > > >> > > >> 0 - CARDINALs are an integral type defined by the language > > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > > >> a change was made to CM3 to extend the language it recognizes > > >> beyond the original language spec (SPWM3), now CM3 understands > > >> a LONGINT. > > >> > > >> Was there a corresponding LONGCARD defined? > > >> > > > > > > No. But you can write: > > > > > > [0L..LAST(LONGINT)] > > > > > > just as > > > > > > CARDINAL=[0..LAST(INTEGER)] > > > > > Actually, the line above was once true, long long ago, when dinosaurs > > roamed unfettered. CARDINAL was changed to be "just like" > > (but not equal to) [0..LAST(INTEGER)]. This would have been > > maybe early 1990s. > > > > It took me years to figure out what this actually meant, and more > > years to figure out why, but I believe I now know. CARDINAL is not an > > equal type to [0..LAST(INTEGER)], but otherwise has all the same > > properties. This makes the two mutually assignable, which is close > > enough to equal to not matter in most contexts. The exact consequences > > follow from other language rules. > > > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > > machines with different values of LAST(INTEGER)), because the numeric > > value of LAST(INTEGER) is part of the expanded type. The one place this > > matters is if you use pickles to transfer data between machines of different > > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > > of the complete, expanded type definition) is different on the two machines, > > and values of or containing this type cannot be transferred. Exact type > > signature matches are used in pickles to find corresponding types when > > reading. > > > > But pickles handle different sized INTEGER values fine, expanding/shortening > > as needed. Being a leaf in a type definition, INTEGER is always the same > > type on any machine. So CARDINAL was changed to be its own unique > > type too, so it would be possible also to transfer CARDINAL values in > > pickles > > between different word sizes. > > > > So, we really should have a LONGCARD, parallel to CARDINAL. > > > > Note that this also affects network objects, which use pickles to transfer > > values of the objects. > > > > > > > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > > >> the CARDINAL is only 31-bits. > > >> > > > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > > > > > >> > > >> > > >> > > >> +--------------------------------------------------------+ > > >> | Peter P. Eiserloh | > > >> +--------------------------------------------------------+ > > >> > > >> > > >> > > >> > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 17 02:55:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Dec 2009 01:55:15 +0000 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, , <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, , <4B2965B7.6040304@lcwb.coop>, , Message-ID: These would be "base" types and people would have to pick and chose their own typedefs to suit their needs. Imho the idea of a "natural" size is a nice theory but it turns out that "we" (in the larger software world) are stuck with the exact sizes as they happen to have been for a while. C int will always be 32 bits. Growing it will break too much code. Even if processors get natural 128 bit integers, they will still always have to deal efficiently with 32 bit integers because 32 bit integers won't go away. Ditto now 64bit integers. As well natural is great for a local variable, but as soon as you start allocating things in large numbers, you start wanting the size to not be much larger than is needed and you consider the range you'll actually need..sometimes it is obviously small, sometimes not. If it isn't obviously small then you can err toward a larger type like or int or size_t. If it is obviously a small range and allocated in large number then you'll more seriously consider UINT8 or UINT16. If the range is unavoidably huge then you'll consider floating point or a multiple precision option. Granted, Modula-3 does have "BITS FOR" and subranges. I'm not used to having those. So maybe these types aren't needed since you can build them. The compiler does certainly have these exact types internally though. And the processors generally all have instructions that operate on them (with varying efficiency though). If you consider C, people often have int, long, long long. This is as I said dumb because what will 128 integers be called, "long long long"? "byte", "short", "long" these are just funny informal names. A more mechanical system is INT8, INT16, INT32 or PTRDIFF_T. I grant that there is base integer type with the size of a pointer, that doesn't have the exact number of bits encoded. Perhaps Modula-3 doesn't have such a bad legacy codebase? Perhaps growing INTEGER to 64bits didn't break anything and growing it to 128 won't either? Perhaps persistance is generally pickles and they deal better with this stuff, and not like direct blitting? Anyway, - Jay From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 20:10:14 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Oops, forgot to ask On 16 Dec 2009, at 19:52, Jay K wrote: "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. (Actually it would have been useful long ago.) LONGINT could be 128 bits for all its definition cares. It is just something usually (not always) bigger than an INTEGER. I really think "long" is a dumb name.. There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. Now these are dumb names because they wire in the size of the value. In Modula-3 INTEGER is a natural (i.e., word-size) value. - Jay > Date: Wed, 16 Dec 2009 16:56:55 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Oops, forgot to ask > > Tony Hosking wrote: > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > >> Hi Gang, > >> > >> 0 - CARDINALs are an integral type defined by the language > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > >> a change was made to CM3 to extend the language it recognizes > >> beyond the original language spec (SPWM3), now CM3 understands > >> a LONGINT. > >> > >> Was there a corresponding LONGCARD defined? > >> > > > > No. But you can write: > > > > [0L..LAST(LONGINT)] > > > > just as > > > > CARDINAL=[0..LAST(INTEGER)] > > > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in > pickles > between different word sizes. > > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > >> the CARDINAL is only 31-bits. > >> > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > >> > >> > >> > >> +--------------------------------------------------------+ > >> | Peter P. Eiserloh | > >> +--------------------------------------------------------+ > >> > >> > >> > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 06:01:41 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 6 Dec 2009 21:01:41 -0800 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> References: , <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> Message-ID: <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> Clarfication, I meant traced heap allocation, the copying of timezone. Could copy to local array then enable switching then alloc/copy. But what I did should be ok. - Jay (phone) On Dec 6, 2009, at 11:14 AM, Tony Hosking wrote: > On 6 Dec 2009, at 09:29, Jay K wrote: > >> I was thinking of that -- DisableSwitching / EnableSwitching -- but >> can the heap allocation happen while >> switching is disabled? > > Yes, it sure can. DisableSwitching/EnableSwitching is exactly what > is needed whenever you are dealing with libraries that are not > thread safe with the user-level thread-switching. > >> I came up with something a bit hacky but maybe ok. >> >> - Jay >> >> >> Subject: Re: [M3devel] DateBsd.m3 lock usually not needed >> From: hosking at cs.purdue.edu >> Date: Sun, 6 Dec 2009 09:25:58 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> That's what SchedulerPosix (badly named but linked to the old user- >> threads naming) is for.... >> >> 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 6 Dec 2009, at 06:48, Jay K wrote: >> >> It'd be nice if DateBsd.m3 only used a lock with user threads and >> not with pthreads/ntthreads. >> >> - Jay >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 17 03:24:36 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Dec 2009 21:24:36 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <4B2965B7.6040304@lcwb.coop> Message-ID: <20091217022436.GC15937@topoi.pooq.com> On Thu, Dec 17, 2009 at 12:52:06AM +0000, Jay K wrote: > > I really think "long" is a dumb name.. > > There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, > UINT64, and unsigned and signed integers the same size of a pointer, > possibly called INT and UINT, or size_t and ptrdiff_t.. Well, in Modula 3, it probably should something like SIZE and PRTDIFF. -- hendrik From hosking at cs.purdue.edu Thu Dec 17 04:41:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 22:41:29 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> References: , <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> Message-ID: <0E815D43-FD27-4304-874D-928D96317389@cs.purdue.edu> Yes, heap allocation can happen while switching is disabled. On 7 Dec 2009, at 00:01, jay.krell at cornell.edu wrote: > Clarfication, I meant traced heap allocation, the copying of timezone. Could copy to local array then enable switching then alloc/copy. But what I did should be ok. > > - Jay (phone) > > On Dec 6, 2009, at 11:14 AM, Tony Hosking wrote: > >> On 6 Dec 2009, at 09:29, Jay K wrote: >> >>> I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while >>> switching is disabled? >> >> Yes, it sure can. DisableSwitching/EnableSwitching is exactly what is needed whenever you are dealing with libraries that are not thread safe with the user-level thread-switching. >> >>> I came up with something a bit hacky but maybe ok. >>> >>> - Jay >>> >>> >>> Subject: Re: [M3devel] DateBsd.m3 lock usually not needed >>> From: hosking at cs.purdue.edu >>> Date: Sun, 6 Dec 2009 09:25:58 -0500 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... >>> >>> 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 6 Dec 2009, at 06:48, Jay K wrote: >>> >>> It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. >>> >>> - Jay >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 17 16:08:41 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 09:08:41 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> Message-ID: <4B2A4979.7020401@lcwb.coop> Tony Hosking wrote: > This does not make sense: > > Here is the compiler's definition of the builtin CARDINAL type: > > MODULE Card; > > IMPORT SubrangeType, Target, TInt, Tipe, Int; > > PROCEDURE Initialize () = > BEGIN > T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); CARDINAL is builtin -----------------------------------------------^ > Tipe.Define ("CARDINAL", T, TRUE); > END Initialize; > > BEGIN > END Card. > > > Notice that it is a subrange type [0..LAST(INTEGER)]. > > 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 > And from MODULE SubrangeType: .... PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = VAR b: P := t; BEGIN Seal (a); Seal (b); RETURN (a.builtin = b.builtin) ^ --- builtin property must be the same for type equality AND TInt.EQ (a.min, b.min) AND TInt.EQ (a.max, b.max) AND Type.IsEqual (a.baseType, b.baseType, x); END EqualChk; ... PROCEDURE Parse (): Type.T = TYPE TK = Token.T; VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); Programmer-defined subrange is not builtin -- ^ BEGIN Match (TK.tLBRACKET); p.minE := Expr.Parse (); Match (TK.tDOTDOT); p.maxE := Expr.Parse (); Match (TK.tRBRACKET); RETURN p; END Parse; This program: MODULE Card EXPORTS Main ; TYPE C = CARDINAL ; TYPE D = [ 0 .. LAST ( INTEGER ) ] ; PROCEDURE DP ( VAR DPF : D ) = BEGIN DPF := 0 END DP ; PROCEDURE CP ( VAR CPF : C ) = BEGIN CPF := 0 END CP ; PROCEDURE Try ( ) = VAR CV : C ; VAR DV : D ; BEGIN CP ( CV ) ; CP ( DV ) <--- line 20 ; DP ( CV ) ; DP ( DV ) END Try ; BEGIN Try ( ) END Card . Gives these errors: rodney at allegheny:~/proj/m3/exp/card/src$ cm3 --- building in ../AMD64_LINUX --- new source -> compiling Card.m3 "../src/Card.m3", line 20: incompatible types (CPF) "../src/Card.m3", line 21: incompatible types (DPF) 2 errors encountered compilation failed => not building program "prog" Fatal Error: package build failed From hosking at cs.purdue.edu Thu Dec 17 17:12:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Dec 2009 11:12:26 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2A4979.7020401@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> <4B2A4979.7020401@lcwb.coop> Message-ID: <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> Aha! Thanks Rodney. Do we have any use-cases for LONGCARD? On 17 Dec 2009, at 10:08, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> This does not make sense: >> Here is the compiler's definition of the builtin CARDINAL type: >> MODULE Card; >> IMPORT SubrangeType, Target, TInt, Tipe, Int; >> PROCEDURE Initialize () = >> BEGIN >> T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); > > CARDINAL is builtin -----------------------------------------------^ > >> Tipe.Define ("CARDINAL", T, TRUE); >> END Initialize; >> BEGIN >> END Card. >> Notice that it is a subrange type [0..LAST(INTEGER)]. >> 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 > > And from MODULE SubrangeType: > > .... > > PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = > VAR b: P := t; > BEGIN > Seal (a); Seal (b); > RETURN (a.builtin = b.builtin) > > ^ --- builtin property must be the same for type equality > > AND TInt.EQ (a.min, b.min) > AND TInt.EQ (a.max, b.max) > AND Type.IsEqual (a.baseType, b.baseType, x); > END EqualChk; > > ... > > PROCEDURE Parse (): Type.T = > TYPE TK = Token.T; > VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); > > Programmer-defined subrange is not builtin -- ^ > > BEGIN > Match (TK.tLBRACKET); > p.minE := Expr.Parse (); > Match (TK.tDOTDOT); > p.maxE := Expr.Parse (); > Match (TK.tRBRACKET); > RETURN p; > END Parse; > > This program: > > MODULE Card EXPORTS Main > > ; TYPE C = CARDINAL > ; TYPE D = [ 0 .. LAST ( INTEGER ) ] > > ; PROCEDURE DP ( VAR DPF : D ) > = BEGIN > DPF := 0 > END DP > ; PROCEDURE CP ( VAR CPF : C ) > = BEGIN > CPF := 0 > END CP > > ; PROCEDURE Try ( ) > = VAR CV : C > ; VAR DV : D > ; BEGIN > CP ( CV ) > ; CP ( DV ) <--- line 20 > ; DP ( CV ) > ; DP ( DV ) > END Try > > ; BEGIN > Try ( ) > END Card -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Thu Dec 17 17:18:32 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 17 Dec 2009 08:18:32 -0800 (PST) Subject: [M3devel] INTEGER vice INT32 Message-ID: <213164.34773.qm@web56804.mail.re3.yahoo.com> Hi Tony, Both Jay, and yourself have valid points. One can classify the two kinds of types, as implicit, and explicit. More specifically, INTEGER is implicit, and is useful for in-memory representation. This was especially important when machine registers were very different between machines. Very few remember the days of 18-bit words, with 9-bit bytes (thank you!). An implicit type is very useful, when you are not worried about external representation and all one needs is the logical behavior of the type, independent of the particular machine on which one may currently be. Explicit types are much more useful, if not imperative, when defining data types for external storage (in files, or network protocols). For binary file IO many people take a naive approach, and simply overlay a data structure onto the file stream. This ignores the potential difference in sizes of implicit types, and their endianess. A more careful method of doing binary files, is to distinguish the external from the internal representation, and have procedures to do the IO a field at a time. See binIO. Back in the late 1980's, and early 1990s, I had an Amiga computer, and had two different "C" compilers: Aztec, C and SAS/C. The Aztec compiler int was 16-bits, whereas the SAS/C int was 32 bits. As you can imagine this caused all sorts of havoc. The Amiga system includes were rewritten with somewhat more explicit types. These were macros such as ULONG, SLONG, USHORT, SSHORT, UBYTE, and SBYTE. This illustrates the importance of explicit types. Both implicit and explicit types have their place. Peter Date: Wed, 16 Dec 2009 20:10:14 -0500 From: Tony Hosking Subject: Re: [M3devel] Oops, forgot to ask To: Jay K Cc: m3devel Message-ID: Content-Type: text/plain; charset="us-ascii" >On 16 Dec 2009, at 19:52, Jay K wrote: > >> "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 >bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? >> >> >> See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. >> (Actually it would have been useful long ago.) > >LONGINT could be 128 bits for all its definition cares. It is just >something usually (not always) bigger than an INTEGER. > >> I really think "long" is a dumb name.. >> There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, >UINT64, and unsigned and signed integers the same size of a pointer, >possibly called INT and UINT, or size_t and ptrdiff_t.. > >Now these are dumb names because they wire in the size of the value. > >In Modula-3 INTEGER is a natural (i.e., word-size) value. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Thu Dec 17 17:30:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Dec 2009 11:30:47 -0500 Subject: [M3devel] INTEGER vice INT32 In-Reply-To: <213164.34773.qm@web56804.mail.re3.yahoo.com> References: <213164.34773.qm@web56804.mail.re3.yahoo.com> Message-ID: <92DD86C0-2379-49D0-87B6-DABF67AF3D45@cs.purdue.edu> But we *do* have explicit types in Modula-3. Subranges and BITS FOR let us pretty much do everything we want (the current implementation restrictions are in using underlying in-memory representations for subranges that round to the nearest byte size). 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 17 Dec 2009, at 11:18, Peter Eiserloh wrote: > Hi Tony, > > Both Jay, and yourself have valid points. > > One can classify the two kinds of types, as implicit, and > explicit. > > More specifically, INTEGER is implicit, and is useful for > in-memory representation. This was especially important > when machine registers were very different between machines. > Very few remember the days of 18-bit words, with 9-bit > bytes (thank you!). An implicit type is very useful, > when you are not worried about external representation > and all one needs is the logical behavior of the type, > independent of the particular machine on which one may > currently be. > > Explicit types are much more useful, if not imperative, > when defining data types for external storage (in files, > or network protocols). > > For binary file IO many people take a naive approach, and > simply overlay a data structure onto the file stream. > This ignores the potential difference in sizes of implicit > types, and their endianess. A more careful method of > doing binary files, is to distinguish the external from > the internal representation, and have procedures to do > the IO a field at a time. See binIO. > > Back in the late 1980's, and early 1990s, I had an Amiga > computer, and had two different "C" compilers: Aztec, C > and SAS/C. The Aztec compiler int was 16-bits, whereas > the SAS/C int was 32 bits. As you can imagine this caused > all sorts of havoc. The Amiga system includes were > rewritten with somewhat more explicit types. These were > macros such as ULONG, SLONG, USHORT, SSHORT, UBYTE, and > SBYTE. > > This illustrates the importance of explicit types. > Both implicit and explicit types have their place. > > > Peter > > > > Date: Wed, 16 Dec 2009 20:10:14 -0500 > From: Tony Hosking > Subject: Re: [M3devel] Oops, forgot to ask > To: Jay K > Cc: m3devel > Message-ID: > Content-Type: text/plain; charset="us-ascii" > >> On 16 Dec 2009, at 19:52, Jay K wrote: >> >>> "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 >> bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? >>> >>> >>> See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. >>> (Actually it would have been useful long ago.) >> >> LONGINT could be 128 bits for all its definition cares. It is just >> something usually (not always) bigger than an INTEGER. >> >>> I really think "long" is a dumb name.. >>> There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, >> UINT64, and unsigned and signed integers the same size of a pointer, >> possibly called INT and UINT, or size_t and ptrdiff_t.. >> >> Now these are dumb names because they wire in the size of the value. >> >> In Modula-3 INTEGER is a natural (i.e., word-size) value. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Thu Dec 17 18:46:31 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 17 Dec 2009 09:46:31 -0800 (PST) Subject: [M3devel] Widechar literals [Was Re: Oops, forgot to ask (Rodney M. Bates) Message-ID: <220296.21268.qm@web56805.mail.re3.yahoo.com> Thank you Rodney. So, if I wanted to represent GREEK SMALL LETTER ALPHA: CONST GreekSmallAlpha = W'03B1'; (* WIDECHAR *) I may not have understood properly. This is not explained in http://www.opencm3.net/doc/reference/texts.html There should be a way of specifying that this is a hex value. Octal values are of course introduced with a backslash followed by a three octal digits. I would have liked to see something like a backslash followed by an x or X and four hexadecimal digits to give the 16-bit value. As in W'\x03B1'. If we were to ever get full unicode support (20-bits) we may need an escape for it. The unicode standard lists code points as in "U+003B1", so a similar escape may look like W'\u003B1'. Next question: are the hexadecimal digits case insensitive? Peter >Date: Wed, 16 Dec 2009 17:35:29 -0600 >From: "Rodney M. Bates" >Subject: Re: [M3devel] Oops, forgot to ask >To: M3Devel >Message-ID: <4B296EC1.1080407 at lcwb.coop> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Peter Eiserloh wrote: >> Hi Gang, >> >> >> >> 1 - How does one write a WIDECHAR literal? Are WIDECHAR >> currently only 16-bits? If so they are limited to only >> the basic multilingual plane (BMP). > >Put a 'W' or 'w' immediately before the opening single >quote of a character literal, and it becomes a WIDECHAR >literal. It has type WIDECHAR, allows characters with >16-bit codes, and also allows 16-bit octal and hex escapes. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From rodney_bates at lcwb.coop Thu Dec 17 20:30:39 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 13:30:39 -0600 Subject: [M3devel] Widechar literals [Was Re: Oops, forgot to ask (Rodney M. Bates) In-Reply-To: <220296.21268.qm@web56805.mail.re3.yahoo.com> References: <220296.21268.qm@web56805.mail.re3.yahoo.com> Message-ID: <4B2A86DF.3070101@lcwb.coop> If the literal (CHAR or TEXT) is not wide, you can have a backslash followed by exactly 3 octal digits as an escape. Or, backslash, followed by 'x' or 'X', followed by exactly two hex digits. For wide literals (WIDECHAR or TEXT), the number of octal digits is exactly 6 and for hex, exactly four. The hex digits are not case sensitive. The same is true for hex digits in numeric literals too. Peter Eiserloh wrote: > Thank you Rodney. > > So, if I wanted to represent GREEK SMALL LETTER ALPHA: > > CONST > GreekSmallAlpha = W'03B1'; (* WIDECHAR *) > > I may not have understood properly. > > This is not explained in > http://www.opencm3.net/doc/reference/texts.html ^ --- I've put this on my list to fix. > > There should be a way of specifying that this is a > hex value. Octal values are of course introduced > with a backslash followed by a three octal digits. > I would have liked to see something like a backslash > followed by an x or X and four hexadecimal digits > to give the 16-bit value. As in W'\x03B1'. > > If we were to ever get full unicode support (20-bits) > we may need an escape for it. The unicode standard > lists code points as in "U+003B1", so a similar escape > may look like W'\u003B1'. > > > Next question: are the hexadecimal digits case insensitive? > > > > Peter > > >> Date: Wed, 16 Dec 2009 17:35:29 -0600 >> From: "Rodney M. Bates" >> Subject: Re: [M3devel] Oops, forgot to ask >> To: M3Devel >> Message-ID: <4B296EC1.1080407 at lcwb.coop> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Peter Eiserloh wrote: >>> Hi Gang, >>> >>> >>> >>> 1 - How does one write a WIDECHAR literal? Are WIDECHAR >>> currently only 16-bits? If so they are limited to only >>> the basic multilingual plane (BMP). >> Put a 'W' or 'w' immediately before the opening single >> quote of a character literal, and it becomes a WIDECHAR >> literal. It has type WIDECHAR, allows characters with >> 16-bit codes, and also allows 16-bit octal and hex escapes. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > From rodney_bates at lcwb.coop Thu Dec 17 22:29:00 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 15:29:00 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> <4B2A4979.7020401@lcwb.coop> <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> Message-ID: <4B2AA29C.5050708@lcwb.coop> The only one I know of is if you want to a pickle or network object with a long field that is nonnegative, but you want its size to be converted between different native word sizes when reading the pickles. Tony Hosking wrote: > Aha! Thanks Rodney. Do we have any use-cases for LONGCARD? > > On 17 Dec 2009, at 10:08, Rodney M. Bates wrote: > >> >> >> Tony Hosking wrote: >>> This does not make sense: >>> Here is the compiler's definition of the builtin CARDINAL type: >>> MODULE Card; >>> IMPORT SubrangeType, Target, TInt, Tipe, Int; >>> PROCEDURE Initialize () = >>> BEGIN >>> T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); >> >> CARDINAL is builtin -----------------------------------------------^ >> >>> Tipe.Define ("CARDINAL", T, TRUE); >>> END Initialize; >>> BEGIN >>> END Card. >>> Notice that it is a subrange type [0..LAST(INTEGER)]. >>> 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 >> >> And from MODULE SubrangeType: >> >> .... >> >> PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = >> VAR b: P := t; >> BEGIN >> Seal (a); Seal (b); >> RETURN (a.builtin = b.builtin) >> >> ^ --- builtin property must be the same for type equality >> >> AND TInt.EQ (a.min, b.min) >> AND TInt.EQ (a.max, b.max) >> AND Type.IsEqual (a.baseType, b.baseType, x); >> END EqualChk; >> >> ... >> >> PROCEDURE Parse (): Type.T = >> TYPE TK = Token.T; >> VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); >> >> Programmer-defined subrange is not builtin -- ^ >> >> BEGIN >> Match (TK.tLBRACKET); >> p.minE := Expr.Parse (); >> Match (TK.tDOTDOT); >> p.maxE := Expr.Parse (); >> Match (TK.tRBRACKET); >> RETURN p; >> END Parse; >> >> This program: >> >> MODULE Card EXPORTS Main >> >> ; TYPE C = CARDINAL >> ; TYPE D = [ 0 .. LAST ( INTEGER ) ] >> >> ; PROCEDURE DP ( VAR DPF : D ) >> = BEGIN >> DPF := 0 >> END DP >> ; PROCEDURE CP ( VAR CPF : C ) >> = BEGIN >> CPF := 0 >> END CP >> >> ; PROCEDURE Try ( ) >> = VAR CV : C >> ; VAR DV : D >> ; BEGIN >> CP ( CV ) >> ; CP ( DV ) <--- line 20 >> ; DP ( CV ) >> ; DP ( DV ) >> END Try >> >> ; BEGIN >> Try ( ) >> END Card > From jay.krell at cornell.edu Fri Dec 18 19:04:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 18:04:27 +0000 Subject: [M3devel] cas/casp? Message-ID: Tony is this right? conceptually: result := CAS(VAR destination, compare, exchange) old := destination if old := compare then destination = exchange return old bool result := CASP(VAR destination, compare, exchange) P for predicate aka returning bool old := destination if old = compare then destination := exchange return true return false I'm pretty sure it is. I'll have this for 16 bit and 32 bit values shortly, for now requiring a recent Microsoft compiler and it generates function calls. But inlining should be easy enough. And then 8bit and 64bit. Also this will probably not work on 386 or 486 but require Pentium or somesuch. I don't know when various instructions were introduced but I know 386 is much poorer here than modern processors. I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t and not e.g. floating point. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 18 19:23:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 18:23:59 +0000 Subject: [M3devel] cas/casp? In-Reply-To: References: Message-ID: Nevermind. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Fri, 18 Dec 2009 18:04:27 +0000 Subject: [M3devel] cas/casp? Tony is this right? conceptually: result := CAS(VAR destination, compare, exchange) old := destination if old := compare then destination = exchange return old bool result := CASP(VAR destination, compare, exchange) P for predicate aka returning bool old := destination if old = compare then destination := exchange return true return false I'm pretty sure it is. I'll have this for 16 bit and 32 bit values shortly, for now requiring a recent Microsoft compiler and it generates function calls. But inlining should be easy enough. And then 8bit and 64bit. Also this will probably not work on 386 or 486 but require Pentium or somesuch. I don't know when various instructions were introduced but I know 386 is much poorer here than modern processors. I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t and not e.g. floating point. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 19:32:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 13:32:57 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: Message-ID: <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. GENERIC INTERFACE Atomic(Rep); IMPORT RTMachine; TYPE T = Rep.T; PROCEDURE MemoryFence(); (* Guarantees explicit memory ordering for otherwise unordered atomics, and for other memory references wrt atomics. Not useful for ordering ordinary memory references, since those may not race and, if they don't race, always appear to be ordered. *) PROCEDURE CompilerFence(); (* Ensures that prior memory operations appear in the instruction stream before subsequent ones, i.e. the compiler is not allowed to reorder around this. This really has only implementation-defined semantics, but it seems to be useful in ensuring ordering with respect to signal handlers and the like. *) PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) PROCEDURE StoreRelease(VAR var: T; val: T); PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) PROCEDURE LoadAcquire(READONLY var: T): T; TYPE Order = { Raw, Acquire, Release, Ordered }; (* "Raw" ==> This operation is unordered, and may become visible to other threads in an order that is constrained only by ordering constraints on other operations. "Release" ==> All prior memory operations (including ordinary assignments) become visible to a an acquire operation on the same object that sees the resulting value. "Acquire" ==> See above. "Ordered" ==> Both acquire and release ordering properties.*) CONST HasCas = RTMachine.HasCas; CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; (* Most architectures provide a way to return the old value. On those that do not, it can be emulated with an additional load, at the expense of wait-freedom or spurious failure. *) CONST HasWeakCas = RTMachine.HasWeakCas; PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; (* Similar to "Cas", but may fail spuriously, and must be wait-free, if provided. *) CONST HasFetchAdd = RTMachine.HasFetchAdd; PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; CONST HasFetchOr = RTMachine.HasFetchOr; PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; CONST HasFetchAnd = RTMachine.HasFetchAnd; PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; END Atomic. On 18 Dec 2009, at 13:04, Jay K wrote: > Tony is this right? > > > conceptually: > > > result := CAS(VAR destination, compare, exchange) > > > old := destination > if old := compare then > destination = exchange > return old > > > bool result := CASP(VAR destination, compare, exchange) > P for predicate aka returning bool > > > old := destination > if old = compare then > destination := exchange > return true > return false > > > I'm pretty sure it is. > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > a recent Microsoft compiler and it generates function calls. > But inlining should be easy enough. > And then 8bit and 64bit. > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > I don't know when various instructions were introduced but I know > 386 is much poorer here than modern processors. > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > and not e.g. floating point. > > > - Jay From jay.krell at cornell.edu Fri Dec 18 20:06:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 19:06:06 +0000 Subject: [M3devel] cas/casp? In-Reply-To: <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Message-ID: oh. I already got it working. ok. Atomic confuses me in a few ways. I find it terribly confusing on Windows that there are separate compiler and memory fences. I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. It makes no sense to me to allow the processor or compiler to reorder but not both. What is weak cas? Is that loadlocked/storecondition and the caller can loop? Um. There is the Windows terminology InterlockedWhatever. There is the gccc builtins. Can we "sound" close to one of them? Or is this based on some other widely known system? And we don't care about older x86 processors like 386?486 I assume? There seem to have been at least two leaps in functionality here. Old Win32 operating systems provide very few interlocked functions. They provide increment and decrement, that only return <0, 0, >0 of the new value. And Exchange. (This is based on the Visual C++ 2.0 winbase.h) All just on 32bit values. Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 13:32:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cas/casp? > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > GENERIC INTERFACE Atomic(Rep); > > IMPORT RTMachine; > > TYPE T = Rep.T; > > PROCEDURE MemoryFence(); > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > for other memory references wrt atomics. Not useful for ordering > ordinary memory references, since those may not race and, if they don't > race, always appear to be ordered. *) > > PROCEDURE CompilerFence(); > (* Ensures that prior memory operations appear in the instruction stream > before subsequent ones, i.e. the compiler is not allowed to reorder > around this. This really has only implementation-defined semantics, but > it seems to be useful in ensuring ordering with respect to signal > handlers and the like. *) > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > PROCEDURE StoreRelease(VAR var: T; val: T); > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > PROCEDURE LoadAcquire(READONLY var: T): T; > > TYPE Order = { Raw, Acquire, Release, Ordered }; > (* "Raw" ==> This operation is unordered, and may become visible to other > threads in an order that is constrained only by ordering constraints > on other operations. > > "Release" ==> All prior memory operations (including ordinary > assignments) become visible to a an acquire operation on the same > object that sees the resulting value. > > "Acquire" ==> See above. > > "Ordered" ==> Both acquire and release ordering properties.*) > > CONST HasCas = RTMachine.HasCas; > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > (* Most architectures provide a way to return the old value. On those that > do not, it can be emulated with an additional load, at the expense of > wait-freedom or spurious failure. *) > > CONST HasWeakCas = RTMachine.HasWeakCas; > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > provided. *) > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > CONST HasFetchOr = RTMachine.HasFetchOr; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > END Atomic. > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > Tony is this right? > > > > > > conceptually: > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > old := destination > > if old := compare then > > destination = exchange > > return old > > > > > > bool result := CASP(VAR destination, compare, exchange) > > P for predicate aka returning bool > > > > > > old := destination > > if old = compare then > > destination := exchange > > return true > > return false > > > > > > I'm pretty sure it is. > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > a recent Microsoft compiler and it generates function calls. > > But inlining should be easy enough. > > And then 8bit and 64bit. > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > I don't know when various instructions were introduced but I know > > 386 is much poorer here than modern processors. > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > and not e.g. floating point. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 20:12:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 14:12:44 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Message-ID: <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> On 18 Dec 2009, at 14:06, Jay K wrote: > oh. I already got it working. ok. > > Atomic confuses me in a few ways. > > I find it terribly confusing on Windows that there are separate compiler and memory fences. > I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. > It makes no sense to me to allow the processor or compiler to reorder but not both. > > > What is weak cas? It's a CAS that can fail spuriously. i.e., even if the old value was ==. > Is that loadlocked/storecondition and the caller can loop? > > > Um. There is the Windows terminology InterlockedWhatever. > There is the gccc builtins. > Can we "sound" close to one of them? > Or is this based on some other widely known system? The Atomic interface I posted is based on a proposal for the C++ standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html > And we don't care about older x86 processors like 386?486 I assume? > There seem to have been at least two leaps in functionality here. > Old Win32 operating systems provide very few interlocked functions. > They provide increment and decrement, that only return <0, 0, >0 of the new value. > And Exchange. (This is based on the Visual C++ 2.0 winbase.h) > All just on 32bit values. > > Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. > > And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. > > And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. > >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 18 Dec 2009 13:32:57 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] cas/casp? > > > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > > > GENERIC INTERFACE Atomic(Rep); > > > > IMPORT RTMachine; > > > > TYPE T = Rep.T; > > > > PROCEDURE MemoryFence(); > > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > > for other memory references wrt atomics. Not useful for ordering > > ordinary memory references, since those may not race and, if they don't > > race, always appear to be ordered. *) > > > > PROCEDURE CompilerFence(); > > (* Ensures that prior memory operations appear in the instruction stream > > before subsequent ones, i.e. the compiler is not allowed to reorder > > around this. This really has only implementation-defined semantics, but > > it seems to be useful in ensuring ordering with respect to signal > > handlers and the like. *) > > > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > > PROCEDURE StoreRelease(VAR var: T; val: T); > > > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > > PROCEDURE LoadAcquire(READONLY var: T): T; > > > > TYPE Order = { Raw, Acquire, Release, Ordered }; > > (* "Raw" ==> This operation is unordered, and may become visible to other > > threads in an order that is constrained only by ordering constraints > > on other operations. > > > > "Release" ==> All prior memory operations (including ordinary > > assignments) become visible to a an acquire operation on the same > > object that sees the resulting value. > > > > "Acquire" ==> See above. > > > > "Ordered" ==> Both acquire and release ordering properties.*) > > > > CONST HasCas = RTMachine.HasCas; > > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > > (* Most architectures provide a way to return the old value. On those that > > do not, it can be emulated with an additional load, at the expense of > > wait-freedom or spurious failure. *) > > > > CONST HasWeakCas = RTMachine.HasWeakCas; > > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > > provided. *) > > > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > > > CONST HasFetchOr = RTMachine.HasFetchOr; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > END Atomic. > > > > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > > > Tony is this right? > > > > > > > > > conceptually: > > > > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > > > > old := destination > > > if old := compare then > > > destination = exchange > > > return old > > > > > > > > > bool result := CASP(VAR destination, compare, exchange) > > > P for predicate aka returning bool > > > > > > > > > old := destination > > > if old = compare then > > > destination := exchange > > > return true > > > return false > > > > > > > > > I'm pretty sure it is. > > > > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > > a recent Microsoft compiler and it generates function calls. > > > But inlining should be easy enough. > > > And then 8bit and 64bit. > > > > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > > I don't know when various instructions were introduced but I know > > > 386 is much poorer here than modern processors. > > > > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > > and not e.g. floating point. > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 18 20:32:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 19:32:33 +0000 Subject: [M3devel] cas/casp? In-Reply-To: <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> , <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> Message-ID: Ah, ok. btw another "common" primitive is InterlockedCompareExchange"Double". As in InterlockedCompareExchange64 that's been in x86 a while and InterlockedCompareExchange128 that is newer. There are also often alignment requirements for these things, like to not cross cache line boundaries. We're already ok that way? At least for globals? - Jay Subject: Re: [M3devel] cas/casp? From: hosking at cs.purdue.edu Date: Fri, 18 Dec 2009 14:12:44 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 18 Dec 2009, at 14:06, Jay K wrote: oh. I already got it working. ok. Atomic confuses me in a few ways. I find it terribly confusing on Windows that there are separate compiler and memory fences. I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. It makes no sense to me to allow the processor or compiler to reorder but not both. What is weak cas? It's a CAS that can fail spuriously. i.e., even if the old value was ==. Is that loadlocked/storecondition and the caller can loop? Um. There is the Windows terminology InterlockedWhatever. There is the gccc builtins. Can we "sound" close to one of them? Or is this based on some other widely known system? The Atomic interface I posted is based on a proposal for the C++ standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html And we don't care about older x86 processors like 386?486 I assume? There seem to have been at least two leaps in functionality here. Old Win32 operating systems provide very few interlocked functions. They provide increment and decrement, that only return <0, 0, >0 of the new value. And Exchange. (This is based on the Visual C++ 2.0 winbase.h) All just on 32bit values. Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 13:32:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cas/casp? > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > GENERIC INTERFACE Atomic(Rep); > > IMPORT RTMachine; > > TYPE T = Rep.T; > > PROCEDURE MemoryFence(); > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > for other memory references wrt atomics. Not useful for ordering > ordinary memory references, since those may not race and, if they don't > race, always appear to be ordered. *) > > PROCEDURE CompilerFence(); > (* Ensures that prior memory operations appear in the instruction stream > before subsequent ones, i.e. the compiler is not allowed to reorder > around this. This really has only implementation-defined semantics, but > it seems to be useful in ensuring ordering with respect to signal > handlers and the like. *) > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > PROCEDURE StoreRelease(VAR var: T; val: T); > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > PROCEDURE LoadAcquire(READONLY var: T): T; > > TYPE Order = { Raw, Acquire, Release, Ordered }; > (* "Raw" ==> This operation is unordered, and may become visible to other > threads in an order that is constrained only by ordering constraints > on other operations. > > "Release" ==> All prior memory operations (including ordinary > assignments) become visible to a an acquire operation on the same > object that sees the resulting value. > > "Acquire" ==> See above. > > "Ordered" ==> Both acquire and release ordering properties.*) > > CONST HasCas = RTMachine.HasCas; > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > (* Most architectures provide a way to return the old value. On those that > do not, it can be emulated with an additional load, at the expense of > wait-freedom or spurious failure. *) > > CONST HasWeakCas = RTMachine.HasWeakCas; > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > provided. *) > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > CONST HasFetchOr = RTMachine.HasFetchOr; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > END Atomic. > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > Tony is this right? > > > > > > conceptually: > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > old := destination > > if old := compare then > > destination = exchange > > return old > > > > > > bool result := CASP(VAR destination, compare, exchange) > > P for predicate aka returning bool > > > > > > old := destination > > if old = compare then > > destination := exchange > > return true > > return false > > > > > > I'm pretty sure it is. > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > a recent Microsoft compiler and it generates function calls. > > But inlining should be easy enough. > > And then 8bit and 64bit. > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > I don't know when various instructions were introduced but I know > > 386 is much poorer here than modern processors. > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > and not e.g. floating point. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 21:19:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 15:19:36 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> , <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> Message-ID: <730B2897-39CC-4719-87E2-1C372FBFD734@cs.purdue.edu> On 18 Dec 2009, at 14:32, Jay K wrote: > Ah, ok. > > btw another "common" primitive is InterlockedCompareExchange"Double". > As in InterlockedCompareExchange64 that's been in x86 a while and InterlockedCompareExchange128 that is newer. > > There are also often alignment requirements for these things, like to not cross cache line boundaries. > We're already ok that way? > At least for globals? I think so. Need to check. > > - Jay > > > Subject: Re: [M3devel] cas/casp? > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 14:12:44 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > On 18 Dec 2009, at 14:06, Jay K wrote: > > oh. I already got it working. ok. > > Atomic confuses me in a few ways. > > I find it terribly confusing on Windows that there are separate compiler and memory fences. > I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. > > MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. > > It makes no sense to me to allow the processor or compiler to reorder but not both. > > > What is weak cas? > > It's a CAS that can fail spuriously. i.e., even if the old value was ==. > > Is that loadlocked/storecondition and the caller can loop? > > > Um. There is the Windows terminology InterlockedWhatever. > There is the gccc builtins. > Can we "sound" close to one of them? > Or is this based on some other widely known system? > > The Atomic interface I posted is based on a proposal for the C++ standard: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html > > And we don't care about older x86 processors like 386?486 I assume? > There seem to have been at least two leaps in functionality here. > Old Win32 operating systems provide very few interlocked functions. > They provide increment and decrement, that only return <0, 0, >0 of the new value. > And Exchange. (This is based on the Visual C++ 2.0 winbase.h) > All just on 32bit values. > > Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. > > And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. > > And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. > >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 18 Dec 2009 13:32:57 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] cas/casp? > > > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > > > GENERIC INTERFACE Atomic(Rep); > > > > IMPORT RTMachine; > > > > TYPE T = Rep.T; > > > > PROCEDURE MemoryFence(); > > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > > for other memory references wrt atomics. Not useful for ordering > > ordinary memory references, since those may not race and, if they don't > > race, always appear to be ordered. *) > > > > PROCEDURE CompilerFence(); > > (* Ensures that prior memory operations appear in the instruction stream > > before subsequent ones, i.e. the compiler is not allowed to reorder > > around this. This really has only implementation-defined semantics, but > > it seems to be useful in ensuring ordering with respect to signal > > handlers and the like. *) > > > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > > PROCEDURE StoreRelease(VAR var: T; val: T); > > > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > > PROCEDURE LoadAcquire(READONLY var: T): T; > > > > TYPE Order = { Raw, Acquire, Release, Ordered }; > > (* "Raw" ==> This operation is unordered, and may become visible to other > > threads in an order that is constrained only by ordering constraints > > on other operations. > > > > "Release" ==> All prior memory operations (including ordinary > > assignments) become visible to a an acquire operation on the same > > object that sees the resulting value. > > > > "Acquire" ==> See above. > > > > "Ordered" ==> Both acquire and release ordering properties.*) > > > > CONST HasCas = RTMachine.HasCas; > > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > > (* Most architectures provide a way to return the old value. On those that > > do not, it can be emulated with an additional load, at the expense of > > wait-freedom or spurious failure. *) > > > > CONST HasWeakCas = RTMachine.HasWeakCas; > > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > > provided. *) > > > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > > > CONST HasFetchOr = RTMachine.HasFetchOr; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > END Atomic. > > > > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > > > Tony is this right? > > > > > > > > > conceptually: > > > > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > > > > old := destination > > > if old := compare then > > > destination = exchange > > > return old > > > > > > > > > bool result := CASP(VAR destination, compare, exchange) > > > P for predicate aka returning bool > > > > > > > > > old := destination > > > if old = compare then > > > destination := exchange > > > return true > > > return false > > > > > > > > > I'm pretty sure it is. > > > > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > > a recent Microsoft compiler and it generates function calls. > > > But inlining should be easy enough. > > > And then 8bit and 64bit. > > > > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > > I don't know when various instructions were introduced but I know > > > 386 is much poorer here than modern processors. > > > > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > > and not e.g. floating point. > > > > > > > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:30:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:30:47 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. Message-ID: Here is my updated proposal for Modula-3 Atomic Word.T. These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. INTERFACE Atomic; IMPORT Word; TYPE T = Word.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = RTMachine.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:32:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:32:43 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: PS Some of these we probably can implement using existing gcc intrinsics. On 19 Dec 2009, at 18:30, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:35:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:35:31 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> Typo: FetchXAnd should read FetchAnd. On 19 Dec 2009, at 18:30, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 20 07:44:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Dec 2009 06:44:07 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> References: , <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> Message-ID: There should be a link to the C++ proposal? As well, new idea, I like the idea of source files containing a link to their cvsweb page. Not to the specific version, but something fairly "stable". - Jay From: hosking at cs.purdue.edu Date: Sat, 19 Dec 2009 18:35:31 -0500 To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. Typo: FetchXAnd should read FetchAnd. On 19 Dec 2009, at 18:30, Tony Hosking wrote: Here is my updated proposal for Modula-3 Atomic Word.T. These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. INTERFACE Atomic; IMPORT Word; TYPE T = Word.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = RTMachine.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Dec 20 04:53:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 19 Dec 2009 22:53:17 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <20091220035317.GA22518@topoi.pooq.com> On Sat, Dec 19, 2009 at 06:30:47PM -0500, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. It's not quite clear to me what these Orders mean. In particular, I don't see a clear model for the interaction of 'visibility', 'memory writes' and 'threads'. I can certainly find a ways to understand these words, but I can't be sure I understand them the same way as they are intended. Perhaps I lack context that is provided somewhere. -- hendrik From jay.krell at cornell.edu Sun Dec 20 15:57:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Dec 2009 14:57:32 +0000 Subject: [M3devel] int32 vs. integer in compare result? Message-ID: In m3front\src\misc\CG.m3: PROCEDURE Compare (t: ZType; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; cg.compare (t, Target.Integer.cg_type, op); SPop (2, "Compare"); SPush (Type.Int32); END Compare; compare(input type, output type, operation) The integrated backend ignores the output type. The gcc backend does not. Doesn't it seem like in the above, Target.Integer and Int32 should match? That compare is being asked to return a possibly larger result than the front end expects? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Dec 20 17:44:38 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 20 Dec 2009 10:44:38 -0600 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <4B2E5476.5000200@lcwb.coop> Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a > prototype implementation for the C++ memory model standardization > process. At the moment they are not gcc intrinsics, but I expect to see > that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory > locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is > affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per > "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with > "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false > while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchPlus (VAR var:T; incr: T; order := Sequential): T; Presumably -------------------^? Similarly in all the Fetch* procs. > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; Presumably ------------------------^ would be more expressive? > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is > affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use > two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise > have no > undefined behavior. *) To be legal on ADDRESS, either another parallel interface or a set of parallel procedures would be needed. Or else, this interface would have to be known to the core language and allow predefined overloading, similar to builtin operators and functions. The syntax could still be that of an interface. I don't think any existing required interfaces do this now. > > END Atomic. > > > 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 > > > > From hosking at cs.purdue.edu Sun Dec 20 19:15:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 13:15:50 -0500 Subject: [M3devel] int32 vs. integer in compare result? In-Reply-To: References: Message-ID: Yes, this seems odd... Of course, the result is supposed to be a Boolean. Will it matter? On 20 Dec 2009, at 09:57, Jay K wrote: > In m3front\src\misc\CG.m3: > > PROCEDURE Compare (t: ZType; op: Cmp) = > BEGIN > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > cg.compare (t, Target.Integer.cg_type, op); > SPop (2, "Compare"); > SPush (Type.Int32); > END Compare; > > > compare(input type, output type, operation) > > The integrated backend ignores the output type. > The gcc backend does not. > > Doesn't it seem like in the above, Target.Integer and Int32 should match? > That compare is being asked to return a possibly larger result than the > front end expects? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 20:01:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 14:01:08 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2E5476.5000200@lcwb.coop> References: <4B2E5476.5000200@lcwb.coop> Message-ID: <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> Thanks for the typo fixes. On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > To be legal on ADDRESS, either another parallel interface or a set of parallel > procedures would be needed. Or else, this interface would have to be known to > the core language and allow predefined overloading, similar to builtin operators > and functions. The syntax could still be that of an interface. I don't think > any existing required interfaces do this now. Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: GENERIC INTERFACE Atomic(Rep); TYPE T = Rep.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = Rep.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. From hosking at cs.purdue.edu Sun Dec 20 20:43:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 14:43:19 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <20091220035317.GA22518@topoi.pooq.com> References: <20091220035317.GA22518@topoi.pooq.com> Message-ID: On 19 Dec 2009, at 22:53, hendrik at topoi.pooq.com wrote: > It's not quite clear to me what these Orders mean. In particular, > I don't see a clear model for the interaction of 'visibility', 'memory > writes' and 'threads'. I can certainly find a ways to understand these > words, but I can't be sure I understand them the same way as they > are intended. > > Perhaps I lack context that is provided somewhere. These are as defined for the C++0x proposed standard. We should, of course, provide explicit description. Acquire/Release have the semantics you would expect for lock acquire and lock release: acquirers see operations performed by releasers. From rodney_bates at lcwb.coop Mon Dec 21 02:02:48 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 20 Dec 2009 19:02:48 -0600 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> References: <4B2E5476.5000200@lcwb.coop> <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> Message-ID: <4B2EC938.5030703@lcwb.coop> Tony Hosking wrote: > Thanks for the typo fixes. > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > >> To be legal on ADDRESS, either another parallel interface or a set of parallel >> procedures would be needed. Or else, this interface would have to be known to >> the core language and allow predefined overloading, similar to builtin operators >> and functions. The syntax could still be that of an interface. I don't think >> any existing required interfaces do this now. > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: And would it be illegal to try to instantiate with any other type? I presume it would have to be a native word sized value for the implementation, and the Fetch operations would not have meaning for most other types. Also, would the corresponding MODULE and its instantiations not be written in M3, but just builtin to the compiler, like Word? > > GENERIC INTERFACE Atomic(Rep); > > TYPE T = Rep.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = Rep.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > From jay.krell at cornell.edu Mon Dec 21 02:37:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 01:37:29 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2EC938.5030703@lcwb.coop> References: , <4B2E5476.5000200@lcwb.coop>, <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, <4B2EC938.5030703@lcwb.coop> Message-ID: No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). Maybe not 8, but there readily available examples of the others. Search the web for: _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). - Jay > Date: Sun, 20 Dec 2009 19:02:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > Tony Hosking wrote: > > Thanks for the typo fixes. > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > >> procedures would be needed. Or else, this interface would have to be known to > >> the core language and allow predefined overloading, similar to builtin operators > >> and functions. The syntax could still be that of an interface. I don't think > >> any existing required interfaces do this now. > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. > > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? > > > > > GENERIC INTERFACE Atomic(Rep); > > > > TYPE T = Rep.T; > > > > TYPE > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > (* "Relaxed": The operation does not order memory. > > > > "Release": Performs a release operation on the affected memory locations, > > thus making regular memory writes visible to other threads through the > > variable to which it is applied. > > > > "Acquire": Performs an acquire operation on the affected memory > > locations, thus making regular memory writes in other threads released > > through the atomic variable to which it is applied, visible to the > > current thread. > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > "Sequential": The operation has both acquire and release semantics, and > > in addition, has sequentially-consistent operation ordering. *) > > > > CONST IsLockFree = Rep.IsLockFree; > > (* True if the operations are lock-free, false otherwise. *) > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > (* Atomically replace the value in "var" with "val". Memory is affected as > > per "order". The "order" shall be neither "Acquire" nor > > "AcquireRelease". *) > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > (* Atomically return the value in "var". Memory is affected as per "order". > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > (* Atomically replace the value in "var" with "val". Returns the value of > > "var" immediately before the effects. Memory is affected as per order. > > This is a read-modify-write operation and synchronizes with any > > evaluation that reads the updated value. *) > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > desired: T; order := Order.Sequential): BOOLEAN; > > (* Atomically, compares the value in "var" for equality with that in > > "expected", and if true, replaces the value in "var" with "desired", and > > if false, updates the value in "expected" with the value in "var". > > Returns the result of the comparison. The "order" shall be neither > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > and synchronizes with any evaluation that reads the updated value. The > > effect of the CompareSwap operation is: > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > The CompareSwap operation may fail spuriously, that is return false while > > leaving the value in "expected" unchanged. A consequence of spurious > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > expected := Atomic.Load(current); > > DO > > desired := function(expected); > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > *) > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > (* Memory is affected as per "order". Synchronizes with any operation on > > the same variable. The "order" shall not be "Relaxed". *) > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > (* Atomically replace the value in "var" with the result of the operation > > applied to the value in "var" and the given operand. Memory is affected > > as per "order". These operations are read-modify-write operations and > > synchronize with any evaluation that reads the updated value. Returns > > the value of "var" immediately before the effects. > > > > For signed integral types, arithmetic is defined to use two's-complement > > representation. There are no undefined results. For address types, the > > result may be an undefined address, but the operations otherwise have no > > undefined behavior. *) > > > > END Atomic. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 21 03:23:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 21:23:37 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2EC938.5030703@lcwb.coop> References: <4B2E5476.5000200@lcwb.coop> <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> <4B2EC938.5030703@lcwb.coop> Message-ID: <8B7D053E-444A-490B-AF3D-34EA2776B40C@cs.purdue.edu> On 20 Dec 2009, at 20:02, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> Thanks for the typo fixes. >> On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: >>> To be legal on ADDRESS, either another parallel interface or a set of parallel >>> procedures would be needed. Or else, this interface would have to be known to >>> the core language and allow predefined overloading, similar to builtin operators >>> and functions. The syntax could still be that of an interface. I don't think >>> any existing required interfaces do this now. >> Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. It's an interesting question if we could instantiate with other types. For now, I am assuming not. > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? Yes, that would be the goal, though for now we will not rely on compiler support because gcc doesn't yet have everything we need. (It may have some in the existing sync builtins, but they have undefined memory ordering semantics, and probably are only meaningful on Intel x86/x86_64). > >> GENERIC INTERFACE Atomic(Rep); >> TYPE T = Rep.T; >> TYPE >> Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; >> (* "Relaxed": The operation does not order memory. >> "Release": Performs a release operation on the affected memory locations, >> thus making regular memory writes visible to other threads through the >> variable to which it is applied. >> "Acquire": Performs an acquire operation on the affected memory >> locations, thus making regular memory writes in other threads released >> through the atomic variable to which it is applied, visible to the >> current thread. >> "AcquireRelease": The operation has both acquire and release semantics. >> "Sequential": The operation has both acquire and release semantics, and >> in addition, has sequentially-consistent operation ordering. *) >> CONST IsLockFree = Rep.IsLockFree; >> (* True if the operations are lock-free, false otherwise. *) >> PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); >> (* Atomically replace the value in "var" with "val". Memory is affected as >> per "order". The "order" shall be neither "Acquire" nor >> "AcquireRelease". *) >> PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; >> (* Atomically return the value in "var". Memory is affected as per "order". >> The "order" shall be neither "Release" nor "AcquireRelease". *) >> PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; >> (* Atomically replace the value in "var" with "val". Returns the value of >> "var" immediately before the effects. Memory is affected as per order. >> This is a read-modify-write operation and synchronizes with any >> evaluation that reads the updated value. *) >> PROCEDURE CompareSwap(VAR var, expected: T; >> desired: T; order := Order.Sequential): BOOLEAN; >> (* Atomically, compares the value in "var" for equality with that in >> "expected", and if true, replaces the value in "var" with "desired", and >> if false, updates the value in "expected" with the value in "var". >> Returns the result of the comparison. The "order" shall be neither >> "Release" nor "AcquireRelease". This is a read-modify-write operation >> and synchronizes with any evaluation that reads the updated value. The >> effect of the CompareSwap operation is: >> IF var = expected THEN var := desired ELSE expected := var; >> The CompareSwap operation may fail spuriously, that is return false while >> leaving the value in "expected" unchanged. A consequence of spurious >> failure is that nearly all uses of CompareSwap will be in a loop: >> expected := Atomic.Load(current); >> DO >> desired := function(expected); >> WHILE NOT Atomic.CompareSwap(current, expected, desired); >> *) >> PROCEDURE Fence(VAR var: T; order := Order.Sequential); >> (* Memory is affected as per "order". Synchronizes with any operation on >> the same variable. The "order" shall not be "Relaxed". *) >> PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; >> PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; >> PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; >> PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; >> PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; >> (* Atomically replace the value in "var" with the result of the operation >> applied to the value in "var" and the given operand. Memory is affected >> as per "order". These operations are read-modify-write operations and >> synchronize with any evaluation that reads the updated value. Returns >> the value of "var" immediately before the effects. >> For signed integral types, arithmetic is defined to use two's-complement >> representation. There are no undefined results. For address types, the >> result may be an undefined address, but the operations otherwise have no >> undefined behavior. *) >> END Atomic. From hosking at cs.purdue.edu Mon Dec 21 03:25:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 21:25:30 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: , <4B2E5476.5000200@lcwb.coop>, <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, <4B2EC938.5030703@lcwb.coop> Message-ID: <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> If we build on the libatomic_ops support then some types might end up with (slow) implementation using locks. On 20 Dec 2009, at 20:37, Jay K wrote: > No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). > Maybe not 8, but there readily available examples of the others. > > Search the web for: > _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx > _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx > _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx > > Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). > > - Jay > > > > Date: Sun, 20 Dec 2009 19:02:48 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > > > > > Tony Hosking wrote: > > > Thanks for the typo fixes. > > > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > > >> procedures would be needed. Or else, this interface would have to be known to > > >> the core language and allow predefined overloading, similar to builtin operators > > >> and functions. The syntax could still be that of an interface. I don't think > > >> any existing required interfaces do this now. > > > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > > > And would it be illegal to try to instantiate with any other type? I presume it would > > have to be a native word sized value for the implementation, and the Fetch operations > > would not have meaning for most other types. > > > > Also, would the corresponding MODULE and its instantiations not be written in M3, > > but just builtin to the compiler, like Word? > > > > > > > > GENERIC INTERFACE Atomic(Rep); > > > > > > TYPE T = Rep.T; > > > > > > TYPE > > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > > (* "Relaxed": The operation does not order memory. > > > > > > "Release": Performs a release operation on the affected memory locations, > > > thus making regular memory writes visible to other threads through the > > > variable to which it is applied. > > > > > > "Acquire": Performs an acquire operation on the affected memory > > > locations, thus making regular memory writes in other threads released > > > through the atomic variable to which it is applied, visible to the > > > current thread. > > > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > > > "Sequential": The operation has both acquire and release semantics, and > > > in addition, has sequentially-consistent operation ordering. *) > > > > > > CONST IsLockFree = Rep.IsLockFree; > > > (* True if the operations are lock-free, false otherwise. *) > > > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > > (* Atomically replace the value in "var" with "val". Memory is affected as > > > per "order". The "order" shall be neither "Acquire" nor > > > "AcquireRelease". *) > > > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > > (* Atomically return the value in "var". Memory is affected as per "order". > > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > > (* Atomically replace the value in "var" with "val". Returns the value of > > > "var" immediately before the effects. Memory is affected as per order. > > > This is a read-modify-write operation and synchronizes with any > > > evaluation that reads the updated value. *) > > > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > > desired: T; order := Order.Sequential): BOOLEAN; > > > (* Atomically, compares the value in "var" for equality with that in > > > "expected", and if true, replaces the value in "var" with "desired", and > > > if false, updates the value in "expected" with the value in "var". > > > Returns the result of the comparison. The "order" shall be neither > > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > > and synchronizes with any evaluation that reads the updated value. The > > > effect of the CompareSwap operation is: > > > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > > > The CompareSwap operation may fail spuriously, that is return false while > > > leaving the value in "expected" unchanged. A consequence of spurious > > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > > > expected := Atomic.Load(current); > > > DO > > > desired := function(expected); > > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > > *) > > > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > > (* Memory is affected as per "order". Synchronizes with any operation on > > > the same variable. The "order" shall not be "Relaxed". *) > > > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > > (* Atomically replace the value in "var" with the result of the operation > > > applied to the value in "var" and the given operand. Memory is affected > > > as per "order". These operations are read-modify-write operations and > > > synchronize with any evaluation that reads the updated value. Returns > > > the value of "var" immediately before the effects. > > > > > > For signed integral types, arithmetic is defined to use two's-complement > > > representation. There are no undefined results. For address types, the > > > result may be an undefined address, but the operations otherwise have no > > > undefined behavior. *) > > > > > > END Atomic. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 05:24:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 04:24:13 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> References: , , <4B2E5476.5000200@lcwb.coop>, , <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, , <4B2EC938.5030703@lcwb.coop>, , <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> Message-ID: Many operations on non-words sizes are perfectly good, no locks, on x86, AMD64, IA64. _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx It's a processor thing, not an OS thing, so whatever Windows supports is trivial on any other x86/AMD64/IA64 system. - Jay From: hosking at cs.purdue.edu Date: Sun, 20 Dec 2009 21:25:30 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. If we build on the libatomic_ops support then some types might end up with (slow) implementation using locks. On 20 Dec 2009, at 20:37, Jay K wrote:No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). Maybe not 8, but there readily available examples of the others. Search the web for: _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). - Jay > Date: Sun, 20 Dec 2009 19:02:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > Tony Hosking wrote: > > Thanks for the typo fixes. > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > >> procedures would be needed. Or else, this interface would have to be known to > >> the core language and allow predefined overloading, similar to builtin operators > >> and functions. The syntax could still be that of an interface. I don't think > >> any existing required interfaces do this now. > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. > > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? > > > > > GENERIC INTERFACE Atomic(Rep); > > > > TYPE T = Rep.T; > > > > TYPE > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > (* "Relaxed": The operation does not order memory. > > > > "Release": Performs a release operation on the affected memory locations, > > thus making regular memory writes visible to other threads through the > > variable to which it is applied. > > > > "Acquire": Performs an acquire operation on the affected memory > > locations, thus making regular memory writes in other threads released > > through the atomic variable to which it is applied, visible to the > > current thread. > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > "Sequential": The operation has both acquire and release semantics, and > > in addition, has sequentially-consistent operation ordering. *) > > > > CONST IsLockFree = Rep.IsLockFree; > > (* True if the operations are lock-free, false otherwise. *) > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > (* Atomically replace the value in "var" with "val". Memory is affected as > > per "order". The "order" shall be neither "Acquire" nor > > "AcquireRelease". *) > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > (* Atomically return the value in "var". Memory is affected as per "order". > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > (* Atomically replace the value in "var" with "val". Returns the value of > > "var" immediately before the effects. Memory is affected as per order. > > This is a read-modify-write operation and synchronizes with any > > evaluation that reads the updated value. *) > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > desired: T; order := Order.Sequential): BOOLEAN; > > (* Atomically, compares the value in "var" for equality with that in > > "expected", and if true, replaces the value in "var" with "desired", and > > if false, updates the value in "expected" with the value in "var". > > Returns the result of the comparison. The "order" shall be neither > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > and synchronizes with any evaluation that reads the updated value. The > > effect of the CompareSwap operation is: > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > The CompareSwap operation may fail spuriously, that is return false while > > leaving the value in "expected" unchanged. A consequence of spurious > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > expected := Atomic.Load(current); > > DO > > desired := function(expected); > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > *) > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > (* Memory is affected as per "order". Synchronizes with any operation on > > the same variable. The "order" shall not be "Relaxed". *) > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > (* Atomically replace the value in "var" with the result of the operation > > applied to the value in "var" and the given operand. Memory is affected > > as per "order". These operations are read-modify-write operations and > > synchronize with any evaluation that reads the updated value. Returns > > the value of "var" immediately before the effects. > > > > For signed integral types, arithmetic is defined to use two's-complement > > representation. There are no undefined results. For address types, the > > result may be an undefined address, but the operations otherwise have no > > undefined behavior. *) > > > > END Atomic. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 21 10:04:36 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Dec 2009 04:04:36 -0500 Subject: [M3devel] build problems on Windows 2000 Message-ID: <4B2EC19B020000D700069A01@scires.com> I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 07:27:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: <4B2EC19B020000D700069A01@scires.com> References: <4B2EC19B020000D700069A01@scires.com> Message-ID: windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 07:38:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 06:38:33 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: References: <4B2EC19B020000D700069A01@scires.com>, Message-ID: windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 21 21:57:09 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Dec 2009 15:57:09 -0500 Subject: [M3devel] build problems on Windows 2000 Message-ID: <4B2F67D1020000D700069AC6@scires.com> Jay et al: Oops, sorry. I forgot about the SDK requirements for developing Win32 apps. BTW, seems that after Microsoft came out with the 2008 edition of Visual Studio Express, they have dropped the 2005 editions. The 2008 edition doesn't support Windows 2000, so getting the 2005 edition is a bit tricky. I managed to find a C++ 2005 edition after much searching on the web. Likewise, all the Microsoft links for the SDK now point to the newer editions which aren't compatible with Windows 2000. I've managed to find a link to the SDK and am installing it now. Thanks for your help, but we may have trouble supporting Windows 2000 in the future if folks can't get the Microsoft tools for this platform. I wonder if we would be allowed to host old versions of the tools? Regards, Randy >>> Jay K 12/21/09 1:47 AM >>> windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay
From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 .ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Verdana;} windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay
Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 22 00:25:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 23:25:17 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: <4B2F67D1020000D700069AC6@scires.com> References: <4B2F67D1020000D700069AC6@scires.com> Message-ID: Probably we cannot host the old tools. There are independent windows.h, in fact I checked them in, though I did so with a different and now abandoned goal in mind. See m3-win\w32api. We could go that route if people really want. Really I think if people want to support Windows 2000, they should have acquired compiler/linker ahead of time, or do something else like use Cygwin or DigitalMars or such. You can also find everything on eBay. The non-Express tools always come with windows.h, etc. - Jay Date: Mon, 21 Dec 2009 15:57:09 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] build problems on Windows 2000 Jay et al: Oops, sorry. I forgot about the SDK requirements for developing Win32 apps. BTW, seems that after Microsoft came out with the 2008 edition of Visual Studio Express, they have dropped the 2005 editions. The 2008 edition doesn't support Windows 2000, so getting the 2005 edition is a bit tricky. I managed to find a C++ 2005 edition after much searching on the web. Likewise, all the Microsoft links for the SDK now point to the newer editions which aren't compatible with Windows 2000. I've managed to find a link to the SDK and am installing it now. Thanks for your help, but we may have trouble supporting Windows 2000 in the future if folks can't get the Microsoft tools for this platform. I wonder if we would be allowed to host old versions of the tools? Regards, Randy >>> Jay K 12/21/09 1:47 AM >>> windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 22 18:02:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Dec 2009 17:02:23 +0000 Subject: [M3devel] head vs. release threads? Message-ID: Tony can you look at head vs. release m3core/threads and such and decide if you want all of head in release? The changes I know about are - handling low resources in pthread, the can of worms I keep prying on :) - something in user threads, I didn't read enough to understand - other stuff in user threads -- sigaltstack for openbsd I'll get Win32 -- eliminating an extra acquire/release in the InnerWait loop. Beyond that the things to consider are - assertions and dependency on time_t definition and such - keying off of processor or "os" (linux,openbsd, etc.) instead of full platform (amd64_linux, i386_openbsd, etc.) - Uconstants.c is in different order and impossible to read diff; I need to sort it or something Just copying all of head m3core to release is probably fine though I try to be a little arbitrarily slow/methodical as a substitute for being conservative, sometimes, something illogical like that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 22 18:22:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Dec 2009 12:22:04 -0500 Subject: [M3devel] head vs. release threads? In-Reply-To: References: Message-ID: <2A82B86D-732B-45AA-9E93-A142C87CFE2D@cs.purdue.edu> I thought we were aiming for stability in the release branch, rather than new functionality. My preference is to not change the release branch too much so long as fundamental functionality is there and correct... On 22 Dec 2009, at 12:02, Jay K wrote: > Tony can you look at head vs. release m3core/threads and such and decide if you want all of head in release? > The changes I know about are > - handling low resources in pthread, the can of worms I keep prying on :) > - something in user threads, I didn't read enough to understand > - other stuff in user threads -- sigaltstack for openbsd > > I'll get Win32 -- eliminating an extra acquire/release in the InnerWait loop. > > > Beyond that the things to consider are > - assertions and dependency on time_t definition and such > - keying off of processor or "os" (linux,openbsd, etc.) instead of full platform (amd64_linux, i386_openbsd, etc.) > - Uconstants.c is in different order and impossible to read diff; I need to sort it or something > > > Just copying all of head m3core to release is probably fine though I try to be a little arbitrarily > slow/methodical as a substitute for being conservative, sometimes, something illogical like that. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Dec 23 04:42:24 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Dec 2009 03:42:24 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091221150040.B051E2474001@birch.elegosoft.com> Message-ID: <770199.13762.qm@web23608.mail.ird.yahoo.com> Hi all: forgive my ignorance about the actual changes going on below copied M3commit message of Monday, December 21, 16:00:40 but what is this to have gcc code inside the compiler libs, I recommend to check the strict rules about this before performing such changes, Is there any problem getting gcc code inside the runtime libraries, even if this only used in level C code, this gets more C dependences in non-M3 code we are not able to guarantee, better UNSAFE than totally unmarked unsafe again. If this is not the case, and just a piece of m3cc related code I don't disqualify it yet. Thanks in advance --- El lun, 21/12/09, Jay Krell escribi?: > De: Jay Krell > Asunto: [M3commit] CVS Update: cm3 > Para: m3commit at elegosoft.com > Fecha: lunes, 21 de diciembre, 2009 11:00 > CVSROOT: /usr/cvs > Changes by: > jkrell at birch. 09/12/21 16:00:40 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/libgcc/: > libgcc.c > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > cm3/m3-libs/m3core/src/runtime/DS3100/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/POSIX/: > RTOSbrk.c RTOSmmap.c > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/SOLsun/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/WIN32/: > RTOSc.c > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > Log message: > add mising #ifdef cplusplus extern "C" { > } > > From dabenavidesd at yahoo.es Wed Dec 23 05:47:27 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Dec 2009 04:47:27 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <770199.13762.qm@web23608.mail.ird.yahoo.com> Message-ID: <468779.46976.qm@web23608.mail.ird.yahoo.com> Hi again: I recall to have said about a virtualization infrastructure future framework for CM3 reusing existing work made by DEC and SPIN, if we manage to get the system running as a separate process in a given processor we will be definitely getting source code level compability between UNIX implementations by means of a huge historical system like DEC UNIX and a good balance on terms of security in the Modula-3 runtime protection of foreign code. If there is no case of having user level DEC Unix server running in a host processor we can still emulate like they did and/or have a M3 Unix server inside the kernel like they planed to do. In perspective SPINE (spin development) developed a embedded system in NT kernel without touching host system processor but the actual network interface card internal processor featuring several M3 applications running on it. This would be a potential place for higher optimization in the CM3 system as we wouldn't have the usual architecture M3 guest-per system but a M3 host per system given the opportunities for it Hope this helps in something, thanks in advance --- El mar, 22/12/09, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] [M3commit] CVS Update: cm3 > Para: m3commit at elegosoft.com, jkrell at elego.de > CC: m3devel at elegosoft.com > Fecha: martes, 22 de diciembre, 2009 22:42 > Hi all: > forgive my ignorance about the actual changes going on > below copied M3commit message of Monday, December 21, > 16:00:40 but what is this to have gcc code inside the > compiler libs, I recommend to check the strict rules about > this before performing such changes, Is there any problem > getting gcc code inside the runtime libraries, even if this > only used in level C code, this gets more C dependences in > non-M3 code we are not able to guarantee, better UNSAFE than > totally unmarked unsafe again. If this is not the case, and > just a piece of m3cc related code I don't disqualify it > yet. > Thanks in advance > > --- El lun, 21/12/09, Jay Krell > escribi?: > > > De: Jay Krell > > Asunto: [M3commit] CVS Update: cm3 > > Para: m3commit at elegosoft.com > > Fecha: lunes, 21 de diciembre, 2009 11:00 > > CVSROOT: /usr/cvs > > Changes by: > > jkrell at birch. 09/12/21 16:00:40 > > > > Modified files: > > > cm3/m3-libs/m3core/src/Csupport/libgcc/: > > libgcc.c > > > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > > > > cm3/m3-libs/m3core/src/runtime/DS3100/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/POSIX/: > > RTOSbrk.c RTOSmmap.c > > > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/SOLsun/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/WIN32/: > > RTOSc.c > > > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > > > Log message: > > add mising #ifdef cplusplus > extern "C" { > > } > > > > > > > > From jay.krell at cornell.edu Wed Dec 23 11:15:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Dec 2009 10:15:51 +0000 Subject: [M3devel] libgcc.c In-Reply-To: <770199.13762.qm@web23608.mail.ird.yahoo.com> References: <20091221150040.B051E2474001@birch.elegosoft.com>, <770199.13762.qm@web23608.mail.ird.yahoo.com> Message-ID: Daniel, please look at the file. If you write the following sorts of Modula-3 code: PROCEDURE Add64(a,b: LONGINT):LONGINT= RETURN a + b; END Add64; PROCEDURE Mult64(a,b: LONGINT):LONGINT= RETURN a * b; END Mult64; PROCEDURE Div64(a,b: LONGINT):LONGINT= RETURN a / b; END Div64; Or the following sorts of C code: long long add64(long long a, long long b) { return a + b; } long long mult64(long long a, long long b) { return a * b; } long long div64(long long a, long long b) { return a / b; } fanything that does these operations, not just functions that /only/ do them, on some architectures (esp. 32 bit ones), the backend (or C compiler) will emit function calls. If gcc is the compiler/linker, it always throws libgcc.a or such, and the functions are resolved. Any C code has this property. libgcc.a is liberally licensed. Again, any C code possibly links in this code. On systems where m3cg is the backend but gcc is not the compiler/linker, e.g. SOLsun, you don't get libgcc.a, but you still get these function calls. Therefore, on a platform like SOLsun, the solution is write functions very much like the above, but with names that match what the backend emits. In fact, what might occur is Sun CC emits function calls to functions with yet other names. That's awfully inefficient (two function calls to do a multiply) but it does work. It might be good if we could teach m3cg about the function names used by other compilers/runtimes. But it's also probably only a problem on 32bit platforms and they are the past. Apparently there is some doubt as to if these functions are needed on 64bit platforms, as you can see in the comments (at least in the original). - Jay > Date: Wed, 23 Dec 2009 03:42:24 +0000 > From: dabenavidesd at yahoo.es > To: m3commit at elegosoft.com; jkrell at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hi all: > forgive my ignorance about the actual changes going on below copied M3commit message of Monday, December 21, 16:00:40 but what is this to have gcc code inside the compiler libs, I recommend to check the strict rules about this before performing such changes, Is there any problem getting gcc code inside the runtime libraries, even if this only used in level C code, this gets more C dependences in non-M3 code we are not able to guarantee, better UNSAFE than totally unmarked unsafe again. If this is not the case, and just a piece of m3cc related code I don't disqualify it yet. > Thanks in advance > > --- El lun, 21/12/09, Jay Krell escribi?: > > > De: Jay Krell > > Asunto: [M3commit] CVS Update: cm3 > > Para: m3commit at elegosoft.com > > Fecha: lunes, 21 de diciembre, 2009 11:00 > > CVSROOT: /usr/cvs > > Changes by: > > jkrell at birch. 09/12/21 16:00:40 > > > > Modified files: > > cm3/m3-libs/m3core/src/Csupport/libgcc/: > > libgcc.c > > > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > > cm3/m3-libs/m3core/src/runtime/DS3100/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/POSIX/: > > RTOSbrk.c RTOSmmap.c > > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/SOLsun/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/WIN32/: > > RTOSc.c > > > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > > > Log message: > > add mising #ifdef cplusplus extern "C" { > > } > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 23 23:50:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Dec 2009 22:50:52 +0000 Subject: [M3devel] Atomic In-Reply-To: <20091223223914.03AD02474001@birch.elegosoft.com> References: <20091223223914.03AD02474001@birch.elegosoft.com> Message-ID: Can/should we have something like AtomicWordPair or AtomicWordArray2? TYPE WordPair = RECORD a,b: Word.T END; or TYPE WordArray2 = ARRAY[0..1] of Word.T; Because modern x86 and very modern AMD64 can support Atomic.CompareExchange(WordPair). I kind of think there should also be AtomicShort or AtomicInt16 for completeness. I realize WideChar covers it, but then, char==boolean also, right? I forget what BYTESIZE(BOOLEAN) is actually. The obvious candidates are 1 and BYTESIZE(INTEGER) and 4 ("int"). For that matter..there aren't clearly 32bit operations on 64bit platforms (depending upon boolean). Which all goes to my earlier repeated point.. Atomic8, Atomic16, Atomic32, Atomic64, Atomic128, AtomicInt = Atomic32 or Atomic64, AtomicLongInt = Atomic64, AtomicWideChar = Atomic16, AtomicBool = Atomic8 or AtomicInt... - Jay > Date: Wed, 23 Dec 2009 23:39:13 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 09/12/23 23:39:13 > > Added files: > cm3/m3-libs/m3core/src/atomic/: Atomic.ig AtomicAddress.i3 > AtomicBoolean.i3 AtomicChar.i3 > AtomicInteger.i3 > AtomicLongint.i3 AtomicRefany.i3 > AtomicWideChar.i3 AtomicWord.i3 > > Log message: > Working up the Atomic interface. Comments welcome. > No implementation yet, so don't try using these... you'll get linkage errors. > But they do compile. ;-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 24 01:12:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Dec 2009 19:12:02 -0500 Subject: [M3devel] Atomic In-Reply-To: References: <20091223223914.03AD02474001@birch.elegosoft.com> Message-ID: Jay, this is Modula-3 not C. We support atomic on the Modula-3 primitive types. All of the sizes you ask for are supported. Even DCAS for 64-bit on 32-bit I Sent from my iPhone On Dec 23, 2009, at 5:50 PM, Jay K wrote: > Can/should we have something like AtomicWordPair or AtomicWordArray2? > > TYPE WordPair = RECORD a,b: Word.T END; > or TYPE WordArray2 = ARRAY[0..1] of Word.T; > > Because modern x86 and very modern AMD64 can support > Atomic.CompareExchange(WordPair). > > I kind of think there should also be AtomicShort or AtomicInt16 for > completeness. > I realize WideChar covers it, but then, char==boolean also, right? > I forget what BYTESIZE(BOOLEAN) is actually. The obvious candidates > are 1 and BYTESIZE(INTEGER) and 4 ("int"). > > For that matter..there aren't clearly 32bit operations on 64bit > platforms (depending upon boolean). > Which all goes to my earlier repeated point.. Atomic8, Atomic16, > Atomic32, Atomic64, Atomic128, AtomicInt = Atomic32 or Atomic64, > AtomicLongInt = Atomic64, AtomicWideChar = Atomic16, AtomicBool = > Atomic8 or AtomicInt... > > - Jay > > > > Date: Wed, 23 Dec 2009 23:39:13 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/12/23 23:39:13 > > > > Added files: > > cm3/m3-libs/m3core/src/atomic/: Atomic.ig AtomicAddress.i3 > > AtomicBoolean.i3 AtomicChar.i3 > > AtomicInteger.i3 > > AtomicLongint.i3 AtomicRefany.i3 > > AtomicWideChar.i3 AtomicWord.i3 > > > > Log message: > > Working up the Atomic interface. Comments welcome. > > No implementation yet, so don't try using these... you'll get > linkage errors. > > But they do compile. ;-) > > From jay.krell at cornell.edu Thu Dec 24 16:17:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Dec 2009 15:17:54 +0000 Subject: [M3devel] external two level names? Message-ID: Should we have a form of <*external*> that assumes two level names insead of one level names? This would be useful I believe for an initial implementation of Atomic. I don't see how to implement Atomic otherwise, well, other than a lame: Atomic.mg: if BYTESIZE(T) == 4 blah elsif BYTESIZE(T) == 8 blah which I guess is ok, or a switch. It'd also be very useful in the existing code base. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 24 16:35:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Dec 2009 10:35:07 -0500 Subject: [M3devel] external two level names? In-Reply-To: References: Message-ID: <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> I don't understand the question. I have a pretty good idea how to implement atomic without that. On 24 Dec 2009, at 10:17, Jay K wrote: > Should we have a form of <*external*> that assumes two level > names insead of one level names? > > This would be useful I believe for an initial implementation of Atomic. > I don't see how to implement Atomic otherwise, well, other than a lame: > > Atomic.mg: > if BYTESIZE(T) == 4 > blah > elsif BYTESIZE(T) == 8 > blah > > which I guess is ok, or a switch. > > It'd also be very useful in the existing code base. > > - Jay > > > > > From jay.krell at cornell.edu Thu Dec 24 20:57:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Dec 2009 19:57:32 +0000 Subject: [M3devel] external two level names? In-Reply-To: <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> References: , <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> Message-ID: Imagine it is implemented by actual functions and not by the compiler? Like: interface AtomicInteger; <*external AtomicInteger__FetchAdd*> PROCEDURE FetchAdd(...) <*external AtomicInteger__CompareAndSwap*> PROCEDURE CompareAndSwap(...) interface AtomicWchar; <*external AtomicWchar__FetchAdd*> PROCEDURE FetchAdd(...) <*external AtomicWchar__CompareAndSwap*> PROCEDURE CompareAndSwap(...) all by instantiating Atomic.ig. <*external*> generic interface Atomic; PROCEDURE FetchAdd(...) PROCEDURE CompareAndSwap(...) Actually I just realize the language elements are maybe there. There is already a notion of an external interface. But as I understand, in the above, every instantiation would have the same external names. How about we change generic external interfaces to be "two level"? There are situations where the existing behavior would suffice that this would break, like if you had a generic that only operated on pointers but instantiated it for multiple pointer types, in that case using the same external name for every function would be ok. I've never seen an external interface until recently when I made some, let alone a generic external interface so this probably breaks nothing. Even so, we could add syntax to external. That is, this is useful for non-generic too. Interface unix <*external unix__sleep*> PROCEDURE sleep... <*external unix__open*> PROCEDURE open... vs. <*external twolevel*> interface unix; PROCEDURE sleep... PROCEDURE open... Granted, maybe something like: AtomicImpl.i3 <* external atomic__increment8 *> procedure increment8... <* external atomic__increment16 *> procedure increment16... <* external atomic__increment32 *> procedure increment32... <* external atomic__increment64 *> procedure increment64... const something := array of bitcount = {increment8, increment16, increment32, increment64} then you can maybe index into the array by the type size log 2 and call the function...and really really hope it gets optimized to a direct call. But on the other hand...if some versions have special inlining support in the compiler anyway, then you can also just teach the compiler about a size to function name mapping and still have an "external" (non-inlined function) implementation, just with compiler support to map the names. That seems like a reasonable compromise -- "compiler support to map the names". So I'm ok with no new language mechanism, but, of course, there is that philosophy -- build reusable mechanisms, not special cases. (This seems to be a guiding principle of C++ -- instead of special casing memory, all user defined types can have destructors; like the special built in numeric types, user defined types can overload operators and have type conversions, etc.) But often the reusable mechanism is much more difficult to design and implement than some special cases. - Jay > From: hosking at cs.purdue.edu > Date: Thu, 24 Dec 2009 10:35:07 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] external two level names? > > I don't understand the question. > > I have a pretty good idea how to implement atomic without that. > > On 24 Dec 2009, at 10:17, Jay K wrote: > > > Should we have a form of <*external*> that assumes two level > > names insead of one level names? > > > > This would be useful I believe for an initial implementation of Atomic. > > I don't see how to implement Atomic otherwise, well, other than a lame: > > > > Atomic.mg: > > if BYTESIZE(T) == 4 > > blah > > elsif BYTESIZE(T) == 8 > > blah > > > > which I guess is ok, or a switch. > > > > It'd also be very useful in the existing code base. > > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 29 18:47:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Dec 2009 18:47:48 +0100 Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option Message-ID: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> Any ideas? Interaction problem between threads and select? Olaf ----- Forwarded message from bugs at elego.de ----- Date: Tue, 29 Dec 2009 16:23:23 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1080: CVSUPD server hangs if used with -C option To: @MISSING_DOMAIN #1080: CVSUPD server hangs if used with -C option -----------------------------+---------------------------------------------- Reporter: rajeshvadivelu | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: Component: sys | Version: 5.8-RC3 Severity: critical | Keywords: Relnote: | Confidential: no Org: Collabnet | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | -----------------------------+---------------------------------------------- Htr: Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package. Start the cvsupd server with -C option ./cvsupd -b /data/cvsupd -C 2 Try cvsup client to connect to the sever ./cvsup -g -L 2 /tmp/cvsupd.cfg The client connection will hang and after sometime we will get "Inactivity timeout" Fix: Env: -----------------------------+---------------------------------------------- In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the cvsup installed. The server starts find and there was no issues if I start the server without -C option. Starting cvsupd server without -C option $ ./cvsupd -b /u2/site/data/cvsupd 2009.12.29 21:31:05 IST [6225]: CVSup server started 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0 2009.12.29 21:31:05 IST [6225]: Ready to service requests Then I did a client request as below $ ./cvsup -g -L 2 /tmp/cvsupd.cfg Parsing supfile "/tmp/cvsupd.cfg" Connecting to myserver.com Connected to myserver.com Rejected by server: Access denied Will retry at 21:37:09 So the request was successful and I get a valid error message at the client. But when I start the server with -C option like the one as below, requests from client are hanging and eventually getting "Inactivity timeout" after sometime. $ ./cvsupd -b /u2/site/data/cvsupd -C 2 When ever a new client connection was made, this daemon clones another cvsupd process and it also hangs. So none of the client request were processed. Strace of the main cvsupd server process, when a new client request was fired. ----------------------------------- select(4, [3], [], [3], {0, 39000}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0, 553000}) accept(3, {sa_family=AF_INET, sin_port=htons(51221), sin_addr=inet_addr("208.75.198.60")}, [16]) = 6 setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0 setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 gettimeofday({1262103026, 146476}, NULL) = 0 open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7 fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 _llseek(7, 0, [0], SEEK_CUR) = 0 fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 close(7) = 0 gettimeofday({1262103026, 147481}, NULL) = 0 stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No such file or directory) write(5, "\0", 1) = 1 futex(0x91580f0, FUTEX_WAKE, 1) = 1 futex(0x9158098, FUTEX_WAKE, 1) = 1 futex(0x91580b8, FUTEX_WAKE, 1) = 1 futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x9158098, FUTEX_WAKE, 1) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f43708) = 6543 futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1 futex(0x915a460, FUTEX_WAKE, 1) = 1 futex(0x91580f0, FUTEX_WAKE, 1) = 1 futex(0x9158098, FUTEX_WAKE, 1) = 1 futex(0x91580b8, FUTEX_WAKE, 1) = 1 futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x9158098, FUTEX_WAKE, 1) = 0 close(6) = 0 accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) ------------------------------------ gdb backtrace of the main cvsupd server process ------------------------------------ #0 0x00a2a402 in __kernel_vsyscall () #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6 #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78, writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at ../src/unix/Common/UnixC.c:301 #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0xbfed9410) at ../src/thread/PTHREAD/ThreadPThread.m3:900 #4 0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:936 #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:854 #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48, M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458 #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at ../src/FSServer.m3:153 #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:399 #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:113 #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at ../src/runtime/common/RTLinker.m3:122 #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at _m3main.mc:4 ------------------------------------------------ strace of the cloned cvsupd process ----------------------------------- futex(0x91580bc, FUTEX_WAIT, 3, NULL ----------------------------------- gdb backtrace of the cloned cvsupd process ----------------------------------- #0 0x00a2a402 in __kernel_vsyscall () #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8, mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #3 0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c, M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238 #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #5 0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc, M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105 #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243 #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at ../src/FSServer.m3:231 #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at ../src/FSServer.m3:227 #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:399 #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:113 #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at ../src/runtime/common/RTLinker.m3:122 #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at _m3main.mc:4 ------------------------------------------- So it looks like both the main and cloned cvsupd processes were waiting for a response from the kernel call "__kernel_vsyscall ()". Under what condition will this happen? Am I doing something wrong here? -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 From rcolebur at SCIRES.COM Wed Dec 30 01:30:17 2009 From: rcolebur at SCIRES.COM (Randy Coleburn) Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages Message-ID: I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 14:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 13:10:55 +0000 Subject: [M3devel] build problems on 3 packages In-Reply-To: References: Message-ID: I haven't checked obliqparse or caltech-parser yet but I see what you mean in obliqrt. I haven't dug into it yet. == package /Users/jay/dev2/cm3/m3-obliq/obliqrt == +++ /cm3/bin/cm3 -build -override -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in AMD64_DARWIN --- ignoring override("obliqrt", "/Users/jay/dev2/cm3/m3-obliq") /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB "/Users/jay/dev2/cm3/m3-libs/m3core/src/text/Text.i3", line 16,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Real.i3", line 11,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/LongReal.i3", line 10,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Extended.i3", line 9,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/libm3/src/fmtlex/Fmt.i3", line 17,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/events/src/EventNumber.i3", line 78,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/sharedobj/src/SharedObj.i3", line 179,0: semantic analysis suppressed due to import errors "../src/ObValue.i3", line 6,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 1: /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB --procedure-- -line- -file--- exec -- _v_netobj 37 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobjv1 44 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobj 64 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl include_dir 45 /Users/jay/dev2/cm3/m3-obliq/obliqrt/src/m3makefile 9 /Users/jay/dev2/cm3/m3-obliq/obliqrt/AMD64_DARWIN/m3make.args Fatal Error: package build failed *** execution of [] failed *** - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 15:50:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 14:50:35 +0000 Subject: [M3devel] build problems on 3 packages In-Reply-To: References: , Message-ID: Please try again, thanks. These were presumably caught by tinderbox though I didn't check. - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Wed, 30 Dec 2009 13:10:55 +0000 Subject: Re: [M3devel] build problems on 3 packages I haven't checked obliqparse or caltech-parser yet but I see what you mean in obliqrt. I haven't dug into it yet. == package /Users/jay/dev2/cm3/m3-obliq/obliqrt == +++ /cm3/bin/cm3 -build -override -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in AMD64_DARWIN --- ignoring override("obliqrt", "/Users/jay/dev2/cm3/m3-obliq") /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB "/Users/jay/dev2/cm3/m3-libs/m3core/src/text/Text.i3", line 16,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Real.i3", line 11,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/LongReal.i3", line 10,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Extended.i3", line 9,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/libm3/src/fmtlex/Fmt.i3", line 17,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/events/src/EventNumber.i3", line 78,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/sharedobj/src/SharedObj.i3", line 179,0: semantic analysis suppressed due to import errors "../src/ObValue.i3", line 6,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 1: /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB --procedure-- -line- -file--- exec -- _v_netobj 37 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobjv1 44 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobj 64 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl include_dir 45 /Users/jay/dev2/cm3/m3-obliq/obliqrt/src/m3makefile 9 /Users/jay/dev2/cm3/m3-obliq/obliqrt/AMD64_DARWIN/m3make.args Fatal Error: package build failed *** execution of [] failed *** - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 20:46:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 19:46:18 +0000 Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option In-Reply-To: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> Message-ID: There should be nothing special about select and kernel threads, perhaps even select and user threads. The bug report is unusually good, though lacks the config file and the stacks of the other threads. Maybe more later.. - Jay > Date: Tue, 29 Dec 2009 18:47:48 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option > > Any ideas? Interaction problem between threads and select? > > Olaf > > ----- Forwarded message from bugs at elego.de ----- > Date: Tue, 29 Dec 2009 16:23:23 -0000 > From: CM3 > Reply-To: CM3 > Subject: [CM3] #1080: CVSUPD server hangs if used with -C option > To: @MISSING_DOMAIN > > #1080: CVSUPD server hangs if used with -C option > -----------------------------+---------------------------------------------- > Reporter: rajeshvadivelu | Owner: wagner > Type: sw-bug | Status: new > Priority: high | Milestone: > Component: sys | Version: 5.8-RC3 > Severity: critical | Keywords: > Relnote: | Confidential: no > Org: Collabnet | Estimatedhours: 0 > Hours: 0 | Billable: 0 > Totalhours: 0 | > -----------------------------+---------------------------------------------- > Htr: > Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package. > > Start the cvsupd server with -C option > > ./cvsupd -b /data/cvsupd -C 2 > > Try cvsup client to connect to the sever > > ./cvsup -g -L 2 /tmp/cvsupd.cfg > > The client connection will hang and after sometime we will get > "Inactivity timeout" > > > Fix: > > > > Env: > > > -----------------------------+---------------------------------------------- > In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs > repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the > cvsup installed. > > The server starts find and there was no issues if I start the server > without -C option. > > Starting cvsupd server without -C option > > $ ./cvsupd -b /u2/site/data/cvsupd > 2009.12.29 21:31:05 IST [6225]: CVSup server started > 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46 > 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0 > 2009.12.29 21:31:05 IST [6225]: Ready to service requests > > Then I did a client request as below > > $ ./cvsup -g -L 2 /tmp/cvsupd.cfg > Parsing supfile "/tmp/cvsupd.cfg" > Connecting to myserver.com > Connected to myserver.com > Rejected by server: Access denied > Will retry at 21:37:09 > > So the request was successful and I get a valid error message at the > client. > > But when I start the server with -C option like the one as below, requests > from client are hanging and eventually getting "Inactivity timeout" after > sometime. > > $ ./cvsupd -b /u2/site/data/cvsupd -C 2 > > When ever a new client connection was made, this daemon clones another > cvsupd process and it also hangs. So none of the client request were > processed. > > Strace of the main cvsupd server process, when a new client request was > fired. > > ----------------------------------- > select(4, [3], [], [3], {0, 39000}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0, 553000}) > accept(3, {sa_family=AF_INET, sin_port=htons(51221), > sin_addr=inet_addr("208.75.198.60")}, [16]) = 6 > setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0 > setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) > fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 > gettimeofday({1262103026, 146476}, NULL) = 0 > open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7 > fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 > _llseek(7, 0, [0], SEEK_CUR) = 0 > fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 > close(7) = 0 > gettimeofday({1262103026, 147481}, NULL) = 0 > stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No > such file or directory) > write(5, "\0", 1) = 1 > futex(0x91580f0, FUTEX_WAKE, 1) = 1 > futex(0x9158098, FUTEX_WAKE, 1) = 1 > futex(0x91580b8, FUTEX_WAKE, 1) = 1 > futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0x9158098, FUTEX_WAKE, 1) = 0 > clone(child_stack=0, > flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0xb7f43708) = 6543 > futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1 > futex(0x915a460, FUTEX_WAKE, 1) = 1 > futex(0x91580f0, FUTEX_WAKE, 1) = 1 > futex(0x9158098, FUTEX_WAKE, 1) = 1 > futex(0x91580b8, FUTEX_WAKE, 1) = 1 > futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0x9158098, FUTEX_WAKE, 1) = 0 > close(6) = 0 > accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource temporarily > unavailable) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > > ------------------------------------ > > gdb backtrace of the main cvsupd server process > > ------------------------------------ > > #0 0x00a2a402 in __kernel_vsyscall () > #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6 > #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78, > writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at > ../src/unix/Common/UnixC.c:301 > #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4, > M3_A4bqCj_timeout=0xbfed9410) at > ../src/thread/PTHREAD/ThreadPThread.m3:900 > #4 0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c, > M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:936 > #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3, > M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at > ../src/thread/PTHREAD/ThreadPThread.m3:854 > #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48, > M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458 > #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at > ../src/FSServer.m3:153 > #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 > #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:399 > #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:113 > #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at > ../src/runtime/common/RTLinker.m3:122 > #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at > _m3main.mc:4 > ------------------------------------------------ > > > strace of the cloned cvsupd process > > ----------------------------------- > > futex(0x91580bc, FUTEX_WAIT, 3, NULL > > ----------------------------------- > > gdb backtrace of the cloned cvsupd process > > ----------------------------------- > > #0 0x00a2a402 in __kernel_vsyscall () > #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/libpthread.so.0 > #2 0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8, > mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 > #3 0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c, > M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238 > #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8, > M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280 > #5 0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc, > M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105 > #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243 > #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at > ../src/FSServer.m3:231 > #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at > ../src/FSServer.m3:227 > #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 > #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:399 > #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:113 > #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at > ../src/runtime/common/RTLinker.m3:122 > #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at > _m3main.mc:4 > > ------------------------------------------- > > So it looks like both the main and cloned cvsupd processes were waiting > for a response from the kernel call "__kernel_vsyscall ()". Under what > condition will this happen? Am I doing something wrong here? > > -- > Ticket URL: > CM3 > Critical Mass Modula3 Compiler > > > ----- End forwarded message ----- > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 09:18:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:18:08 +0000 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: Oh darn, some hiccup on my phone has caused a bunch of emails to resent. Sorry for the horrendous noise. :( - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 02:02:47 +0000 > Subject: Re: [M3devel] This is a pixmap? > > > Trying again due to truncation. > > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: This is a pixmap? > Date: Thu, 3 Sep 2009 15:44:17 +0000 > > > > Does this look like a pixmap to anyone? > This is the parameter to Win32 Join. > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > t is at @ebp + here. > The pointer then is 00200000 at the start of the second line of the second dump. > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 09:31:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:31:21 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091130160501.GA24572@topoi.pooq.com> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu>, <20091130160501.GA24572@topoi.pooq.com> Message-ID: There certainly is such a campain in general. It has a few "labels". Posix glibc BSD sockets Mono C stdio.h gcc As well as "Linux" and "NT". The challenge then is weaving your way around options such as: chosing a very small number of systems, e.g. just NT chosing a very small number of features, e.g. stdio.h layering on some interface that you believe you can implement on top of multiple other systems e.g. Thread.i3, ThreadWin32.m3, ThreadPThread.m3 with various qualities, costs (maintenance, performance), etc. e.g. Trestle e.g. garbage collection (esp. when combined with Thread.i3) There is no one easy answer here. It helps that "chosing a very small number of systems" is a popular choice, thereby narrowing the field, unless you are/were one of the less popular systems. :) - Jay > Date: Mon, 30 Nov 2009 11:05:01 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > CC: hendrik at topoi.pooq.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > On Mon, Nov 30, 2009 at 09:48:48AM -0500, Tony Hosking wrote: > > This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. > > There seems to be a campaign to make all OS's behave the same to the > lowest possible code level. The only way to do that is to restrict > ourselves to a subset of their facilities that all share. I suspect > this is too restrictive. For popular platforms, at least, we should be > open to implement Modula 3 library features in a way that takes > advantage of those platforms peculiar abilities -- provided that the > library-user facilities remain compatible of course. > > That said, Windows is a popular platform that I have no use for (Windows > won't even install on my most-used machine -- for some obscure reason > it will only run in maintenance mode; my daughter says the machine is > corsed). The only thing I need Windows for is writing programs that > are to uised by other people. For that purpose, I do care that any > Modula 3 applications I write can be cross-compiled (ideally) and > immediately run properly on Windows without modification. > > But I suspect that is too much to expect in the real world, even with > the uncanny competence with which Modula 3 system is put togeter. > > -- hendrik > > > > > On 30 Nov 2009, at 13:03, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 09/11/30 13:03:07 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > > > > > Log message: > > > keep two thread handles > > > what to call them is unclear > > > here we ahve: > > > joinHandle > > > suspendResumeHandle > > > > > > aka: > > > pthread > > > ntthread > > > > > > on all but Interix (and possibly Cygwin), they are equivalent, > > > either the result of pthread_create or pthread_self > > > > > > on Interix, once is pthread_create/self, the other is a kernel handle > > > for suspend/resume > > > > > > alternate names welcome > > > the intent seems hoky, but helps much > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 09:43:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:43:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <6CED57F2-7E8F-4D7C-8DD0-8AE436BEF31B@cs.purdue.edu> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu>, <20091130160501.GA24572@topoi.pooq.com>, <6CED57F2-7E8F-4D7C-8DD0-8AE436BEF31B@cs.purdue.edu> Message-ID: Interest in Interix would probably track similarly with interest in Cygwin. They each have pluses and minuses. Interix in particular has a "normal" fast fork and is therefore far less unpleasant to use, esp. building m3cc. (Tip for Interix users: "net stop beep". I find Interix beeps a lot and the volume can't be controlled or muted (using the normal methods), such as when tab doesn't have anything to complete, etc.) - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 13:21:39 -0500 To: hendrik at topoi.pooq.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I was really just asking what the Interix target was good for. Windows users will want Windows integration, right? Rather than the Interix hybrid... On 30 Nov 2009, at 11:05, hendrik at topoi.pooq.com wrote: On Mon, Nov 30, 2009 at 09:48:48AM -0500, Tony Hosking wrote: This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. There seems to be a campaign to make all OS's behave the same to the lowest possible code level. The only way to do that is to restrict ourselves to a subset of their facilities that all share. I suspect this is too restrictive. For popular platforms, at least, we should be open to implement Modula 3 library features in a way that takes advantage of those platforms peculiar abilities -- provided that the library-user facilities remain compatible of course. That said, Windows is a popular platform that I have no use for (Windows won't even install on my most-used machine -- for some obscure reason it will only run in maintenance mode; my daughter says the machine is corsed). The only thing I need Windows for is writing programs that are to uised by other people. For that purpose, I do care that any Modula 3 applications I write can be cross-compiled (ideally) and immediately run properly on Windows without modification. But I suspect that is too much to expect in the real world, even with the uncanny competence with which Modula 3 system is put togeter. -- hendrik On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 11:06:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 10:06:46 +0000 Subject: [M3devel] Interix In-Reply-To: <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> Message-ID: I should point out that, like NT386, NT386GNU, NT386MINGNU, Interix is also in reality a few variables that can be mixed/matched. You can use either gcc or Visual C++ compiler and linker, and either the gcc backend or the integrated backend. In Interix, gcc is gcc (3.x or possibly 4.2), and cc is a wrapper around Visual C++ cl/link. They both work. For most code, indistinguishably, though definitely a little bit different feature sets. Interix does /not/, at least on XP, provide the other variables like C runtime, threading library, GUI library. After XP they do support "mixed mode" -- access to Win32 -- so then those choices would come back maybe. To help cc work, you can point $C89_COMPILER and $C89_LINKER at Visual C++ compiler/linker. (Similarly, you know, Intel has a compiler you can use on as I understand, Windows, Linux, MacOSX, x86, amd64, ia64?. I'm not sure it gets as much use as either gcc or Visual C++, but it is out there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; jkrell at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 30 Nov 2009 18:15:49 +0000 Interix is Posix (mostly) on NT, with fast fork. Cygwin in comparison is very slow. However SIGINFO is not available. Nor is "direct suspend" using a pthread_t I believe. The older Interix version on XP does not allow access to any Win32 functions. Newer versions do. This does seem to be a pretty useful platfom. Gui should be available too, but I have to work around some problem. - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 09:48:48 -0500 To: jkrell at elego.de CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Dec 1 12:01:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Dec 2009 06:01:54 -0500 Subject: [M3devel] Interix In-Reply-To: References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> Message-ID: <4B14B071.1E75.00D7.1@scires.com> Just out of curiosity, is anyone in the M3 community using or planning to use Interix ? I only plan to use native Windows, not Interix and not Cygwin. If no one wants Interix, perhaps current Interix efforts should be put on hold until the release is completed? Regards, Randy >>> Jay K 12/1/2009 5:06 AM >>> I should point out that, like NT386, NT386GNU, NT386MINGNU, Interix is also in reality a few variables that can be mixed/matched. You can use either gcc or Visual C++ compiler and linker, and either the gcc backend or the integrated backend. In Interix, gcc is gcc (3.x or possibly 4.2), and cc is a wrapper around Visual C++ cl/link. They both work. For most code, indistinguishably, though definitely a little bit different feature sets. Interix does /not/, at least on XP, provide the other variables like C runtime, threading library, GUI library. After XP they do support "mixed mode" -- access to Win32 -- so then those choices would come back maybe. To help cc work, you can point $C89_COMPILER and $C89_LINKER at Visual C++ compiler/linker. (Similarly, you know, Intel has a compiler you can use on as I understand, Windows, Linux, MacOSX, x86, amd64, ia64?. I'm not sure it gets as much use as either gcc or Visual C++, but it is out there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; jkrell at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 30 Nov 2009 18:15:49 +0000 Interix is Posix (mostly) on NT, with fast fork. Cygwin in comparison is very slow. However SIGINFO is not available. Nor is "direct suspend" using a pthread_t I believe. The older Interix version on XP does not allow access to any Win32 functions. Newer versions do. This does seem to be a pretty useful platfom. Gui should be available too, but I have to work around some problem. - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 09:48:48 -0500 To: jkrell at elego.de CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT:/usr/cvs Changes by:jkrell at birch.09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 12:01:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 11:01:10 +0000 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: I don't know if this is my phone or the mail server. Let's try turning off phone.. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 02:02:47 +0000 > Subject: Re: [M3devel] This is a pixmap? > > > Trying again due to truncation. > > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: This is a pixmap? > Date: Thu, 3 Sep 2009 15:44:17 +0000 > > > > Does this look like a pixmap to anyone? > This is the parameter to Win32 Join. > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > t is at @ebp + here. > The pointer then is 00200000 at the start of the second line of the second dump. > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 1 13:44:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Dec 2009 13:44:15 +0100 Subject: [M3devel] Final release sprint? was: Re: Interix In-Reply-To: <4B14B071.1E75.00D7.1@scires.com> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> <4B14B071.1E75.00D7.1@scires.com> Message-ID: <20091201134415.nk1fd6m59w8ocscg@mail.elegosoft.com> Quoting Randy Coleburn : > Just out of curiosity, is anyone in the M3 community using or > planning to use Interix ? > > I only plan to use native Windows, not Interix and not Cygwin. > > If no one wants Interix, perhaps current Interix efforts should be > put on hold until the release is completed? I really don't want to patronize anyone regarding his or her work on CM3, but it seems to be extremely difficult to concentrate the efforts on bringing the release engineering for 5.8 to an end. I currently cannot spend much time at all, and there are still several open tickets. I also haven't seen much (not to say none) feedback on the RC4 archives which are (mostly, some target platforms are still missing) available for several weeks. But in the meantime continuous integration has broken down several times on the release branch, so there must have been significant changes again. Very likely this release has already taken much too long, so that nobody is really interested anymore. It would be a pity if we don't get anything out the door though, as it will without doubt be much better than what was available before. As I said before, I'm unlikely to do any serious investigation or fixing during the next weeks. I can just have a look at the CI and ticket status now and then. If anybody wants to take over release engineering here, that would be OK for me, too; but I think that's rather unlikely, as I only volunteered because there was noone else ;-) So to summarize, I wouldn't say that nobody wants Interix or that it isn't worth the efforts, but I'd really appreciate if we could concentrate our efforts to finish the release. 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 From rodney_bates at lcwb.coop Tue Dec 1 16:35:48 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 01 Dec 2009 09:35:48 -0600 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <4B1537D4.8000909@lcwb.coop> I don't think it is your phone, because I happen to have changed the email address I use in my subscriptions, and the duplicate messages are all coming to the old email address. Must be the list server. Jay K wrote: > I don't know if this is my phone or the mail server. > Let's try turning off phone.. > > - Jay > > From rcoleburn at scires.com Tue Dec 1 20:32:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Dec 2009 14:32:21 -0500 Subject: [M3devel] build problem diagnosis in caltech-parser test package Message-ID: <4B150A90020000D700067FB8@scires.com> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 2 05:12:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Dec 2009 23:12:09 -0500 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> OK, this is getting ridiculous. Can someone at Elego give the mail-list server a poke to make sure it is not them resending as middle-man? Jay, do you have any ideas what could be going on at your end? On 3 Sep 2009, at 11:44, Jay K wrote: > > Does this look like a pixmap to anyone? > > This is the parameter to Win32 Join. > > > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > > t is at @ebp + here. > > The pointer then is 00200000 at the start of the second line of the second dump. > > > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Wed Dec 2 06:12:20 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 01 Dec 2009 21:12:20 -0800 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <20091202051220.E3A5D1A205E@async.async.caltech.edu> Why is this message looping over and over? This and another from Jay of the same day.. I must have received hundreds of copies by now. The messages are dated September 3 and 4. Mika Jay K writes: >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Trying again due to truncation. > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: m3devel at elegosoft.com >Subject: This is a pixmap? >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 > > > >Does this look like a pixmap to anyone? >This is the parameter to Win32 Join. >=20 >PROCEDURE Join(t: T): REFANY =3D > VAR res: REFANY=3B > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= >")=3B END=3B > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B > res :=3D t.result=3B > t.result :=3D NIL=3B > t.joined :=3D TRUE=3B > t.cond :=3D NIL=3B > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B > END=3B > RETURN res=3B > END Join=3B > >Very very often the crash is of the form of reading a pointer from 16 bytes= > into t and dereferencing it=2C plus or minus 4. >t is at @ebp + here. >The pointer then is 00200000 at the start of the second line of the second = >dump. >=20 >If we can confirm this is pixmap=2C we can hunt more around in the gui code= From jay.krell at cornell.edu Wed Dec 2 06:49:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Dec 2009 05:49:08 +0000 Subject: [M3devel] frequently recurring emails In-Reply-To: <20091202051220.E3A5D1A205E@async.async.caltech.edu> References: , <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: I don't know what is happening here but I don't think it is from me. On my end: - none of the messages are signed "phone" so not phone - I turned my phone off for hours so not phone ? - Jay > To: jay.krell at cornell.edu > Date: Tue, 1 Dec 2009 21:12:20 -0800 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] This is a pixmap? > > > Why is this message looping over and over? This and another from > Jay of the same day.. I must have received hundreds of copies by now. > The messages are dated September 3 and 4. > > Mika > > Jay K writes: > >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Trying again due to truncation. > > > >=20 > > > > - Jay > >=20 > > > > > >From: jay.krell at cornell.edu > >To: m3devel at elegosoft.com > >Subject: This is a pixmap? > >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 > > > > > > > >Does this look like a pixmap to anyone? > >This is the parameter to Win32 Join. > >=20 > >PROCEDURE Join(t: T): REFANY =3D > > VAR res: REFANY=3B > > BEGIN > > LOCK threadMu DO > > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= > >")=3B END=3B > > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B > > res :=3D t.result=3B > > t.result :=3D NIL=3B > > t.joined :=3D TRUE=3B > > t.cond :=3D NIL=3B > > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B > > END=3B > > RETURN res=3B > > END Join=3B > > > >Very very often the crash is of the form of reading a pointer from 16 bytes= > > into t and dereferencing it=2C plus or minus 4. > >t is at @ebp + here. > >The pointer then is 00200000 at the start of the second line of the second = > >dump. > >=20 > >If we can confirm this is pixmap=2C we can hunt more around in the gui code= -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Wed Dec 2 09:23:44 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Dec 2009 09:23:44 +0100 Subject: [M3devel] frequently recurring emails In-Reply-To: References: , <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: <20091202092344.rw3vpecq74gocg4g@mail.elego.de> ...looking into it. -Mike Quoting Jay K : > > I don't know what is happening here but I don't think it is from me. > > On my end: > > - none of the messages are signed "phone" so not phone > > - I turned my phone off for hours so not phone > > ? > > > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Tue, 1 Dec 2009 21:12:20 -0800 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] This is a pixmap? >> >> >> Why is this message looping over and over? This and another from >> Jay of the same day.. I must have received hundreds of copies by now. >> The messages are dated September 3 and 4. >> >> Mika >> >> Jay K writes: >> >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ >> >Content-Type: text/plain; charset="iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Trying again due to truncation. >> > >> >=20 >> > >> > - Jay >> >=20 >> > >> > >> >From: jay.krell at cornell.edu >> >To: m3devel at elegosoft.com >> >Subject: This is a pixmap? >> >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 >> > >> > >> > >> >Does this look like a pixmap to anyone? >> >This is the parameter to Win32 Join. >> >=20 >> >PROCEDURE Join(t: T): REFANY =3D >> > VAR res: REFANY=3B >> > BEGIN >> > LOCK threadMu DO >> > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= >> >")=3B END=3B >> > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B >> > res :=3D t.result=3B >> > t.result :=3D NIL=3B >> > t.joined :=3D TRUE=3B >> > t.cond :=3D NIL=3B >> > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B >> > END=3B >> > RETURN res=3B >> > END Join=3B >> > >> >Very very often the crash is of the form of reading a pointer from >> 16 bytes= >> > into t and dereferencing it=2C plus or minus 4. >> >t is at @ebp + here. >> >The pointer then is 00200000 at the start of the second line of >> the second = >> >dump. >> >=20 >> >If we can confirm this is pixmap=2C we can hunt more around in the >> gui code= > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Dec 2 10:03:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 10:03:31 +0100 Subject: [M3devel] Mail problems, was: Re: This is a pixmap? In-Reply-To: <20091202051220.E3A5D1A205E@async.async.caltech.edu> References: <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: <20091202100331.ho1xpesj4s408kc4@mail.elegosoft.com> Quoting Mika Nystrom : > Why is this message looping over and over? This and another from > Jay of the same day.. I must have received hundreds of copies by now. > The messages are dated September 3 and 4. This is strange. I didn't get hundreds of copies so I didn't really notice the problem. Mike is already investigating. If there is anything wrong with our services, please remember to include admins at elego.de, or at least m3-support at elego.de, or directly manderson at elego.de in your To: address. That will speed up the process. 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 From peter.mckinna at gmail.com Wed Dec 2 12:17:44 2009 From: peter.mckinna at gmail.com (peter mckinna) Date: Wed, 2 Dec 2009 22:17:44 +1100 Subject: [M3devel] Coverage tools Message-ID: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> Hi, Does the coverage tool actually work? I tried compiling with the -Z option after fixing up the C code in m3-tools/coverage but no luck. Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 2 12:56:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 12:56:35 +0100 Subject: [M3devel] Coverage tools In-Reply-To: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> References: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> Message-ID: <20091202125635.dcg5bwuo9sgc0wco@mail.elegosoft.com> Quoting peter mckinna : > Hi, > > Does the coverage tool actually work? > > I tried compiling with the -Z option after fixing up the C code in > m3-tools/coverage but no luck. I cannot say. It is probably legacy code from SRC that has not been used for many years and may fail due to various reasons now. We should probably document that. Can you also open a ticket (low priority) for the issue in trac? 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 From michael.anderson at elego.de Wed Dec 2 15:51:08 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Dec 2009 15:51:08 +0100 Subject: [M3devel] This is a pixmap? In-Reply-To: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> References: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> Message-ID: <20091202155108.let6ez86s8osgkc4@mail.elego.de> Hi All, The problem is on our end, not Jay's. I've identified the cause and am cleaning up now. Sorry for the spam. -Mike Quoting Tony Hosking : > OK, this is getting ridiculous. Can someone at Elego give the > mail-list server a poke to make sure it is not them resending as > middle-man? Jay, do you have any ideas what could be going on at > your end? > > On 3 Sep 2009, at 11:44, Jay K wrote: > >> >> Does this look like a pixmap to anyone? >> >> This is the parameter to Win32 Join. >> >> >> >> PROCEDURE Join(t: T): REFANY = >> VAR res: REFANY; >> BEGIN >> LOCK threadMu DO >> IF t.joined THEN Die(ThisLine(), "attempt to join with thread >> twice"); END; >> WHILE NOT t.completed DO Wait(threadMu, t.cond) END; >> res := t.result; >> t.result := NIL; >> t.joined := TRUE; >> t.cond := NIL; >> IF perfOn THEN PerfChanged(t.id, State.dead) END; >> END; >> RETURN res; >> END Join; >> >> >> Very very often the crash is of the form of reading a pointer from >> 16 bytes into t and dereferencing it, plus or minus 4. >> >> t is at @ebp + here. >> >> The pointer then is 00200000 at the start of the second line of the >> second dump. >> >> >> >> If we can confirm this is pixmap, we can hunt more around in the gui code > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Wed Dec 2 18:01:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 2 Dec 2009 09:01:49 -0800 (PST) Subject: [M3devel] Looking to update cm3 manual page. Message-ID: <538131.35719.qm@web56806.mail.re3.yahoo.com> Hi all, It has been more than half a year since I last looked at the CM3 manual page. I am now looking at the it in preparation for the release of version 5.8, and noticing some deficiencies. I asking for help in identifying any further places it is lacking. I can integrate any feedback into a revised manual page, and submit an updated version back to the archives. Currently identified deficiencies: o The manual page should explicitly state which version of the compiler it documents. o The sub-section "Expected Directory Structure" needs a better discussion, especially an introduction. o The discussion of mode option "-ship" mentions environment variable CM3_INSTALL_ROOT, yet in cm3.cfg we set INSTALL_ROOT without the "CM3_" prefix. This should be resolved. ** What is the exact meaning of these two? Is one recognized by the compiler, and the other by the supporting quake code? o The ENVIRONMENT section does not mention CM3_INSTALL_ROOT at all. Add a discussion about both INSTALL_ROOT, and CM3_INSTALL_ROOT. ** Am I missing any other environment variables? o Missing command line options for the compiler: - I currently have "-g", but no discussion of -gstabs. No discussion about not supporting DWARF (or do we?). o Compiler unique language features, (i.e., pragmas). The reference books (Nelson, and Harbison) give a list of suggested pragmas. The manual page should list the ones supported by the CM3 compiler explicitly, and show their syntax. ** Can someone list for me the pragmas supported by the current (5.8.4) compiler. o Should list any limitations of either the compiler, or the library suite provided with the compiler. For example, the WIDECHAR is limited by its 16-bit size to only a portion of the unicode character set (the basic multi lingual plane), whereas a unicode character is 20-bits, and we would need either a 24-bit or 32-bit sized type to contain it all. ** Are there any other known limitations of the compiler, or library suite? - length of identifier? - length of TEXT (ie, memory) - length of filenames, or pathname (some architectures may have differences, ie MS-Windows). o There should be a discussion of the @m3XXX runtime library command line options. o There should be an EXAMPLE section, with example source code (Hello world), along with supporting m3makefile. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Wed Dec 2 18:36:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 18:36:34 +0100 Subject: [M3devel] [Modula-3] Draft press release In-Reply-To: <864527.8311.qm@web56803.mail.re3.yahoo.com> References: <864527.8311.qm@web56803.mail.re3.yahoo.com> Message-ID: <20091202183634.nua52s60gssw4s08@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Olaf, > > I began working on writing a press release for the impending > official release. Would you either suggest any changes, or > simply take it and run with it. It's great that somebody starts to work on advertising! We should wait for the final release before publishing an official press notice though. As there have been many changes to threading again in the release branch, there should at least be an RC5 (which may then become the `official' release). Browsing your text, I don't see any mention of the threading improvements (system based threads default on almost all platforms --> better scaling on multi-processors, improved M3 user threads code) and garbage collection work. Perhaps we could insert some quotes from Antony? You may want to add more changes from the list at http://www.opencm3.net/releng/relnotes-5.8-RC4.html, though not every detail needs to be listed in the press release. cm3ide comes to mind, as well as m3gdb, improved Windows support, and REFANY extensions. > BTW: I went to the download page to download a copy of > the source for version 5.5, but only found binaries for > selected architectures. The sources are there, but `Sources' was missing in the heading. It's the first archive listed. > Also, that section was listed as > "Current Development Snapshots: CM3 d5.5.0". Do we really > want to say "Current"? No. I've removed several `current's :-) > *** BEGIN CUT *** > CM3 V5.8 PRESS RELEASE > > The CM3 software development team is pleased to announce > the release of CM3 version 5.8.4, is now available for > download from > > http://www.opencm3.net/download.html > > CM3 is an open source Modula-3 compiler, descended from the > Critical Mass Modula-3 compiler, which itself came from > Digital Equipment Corp (DEC) Systems Research Center (SRC)'s > m3 compiler. > > This is the first release of the 5.8 branch. It contains > many enhancements over the previous official release (5.5), > including (but not limited by): > > * Language enhancements: > o New primitive type > - LONGINT o Minimal tagged REFANY values > > * New supported architectures: > o AMD64_LINUX > o PPC_DARWIN This is not new, but I386_OPENBSD and AMD64_FREEBSD are. I'm not sure what will finally be available though. > o X86_DARWIN > o etc ... > > * Compiler Improvements > o Rebased on top of GCC-4.1 I think that should be 4.3. > o Additional information provided with version > information. > o Support configuration scripts (in quake) reworked > for more commonality between architectures. Runtime Improvements: o system-based threading default on most target platforms allowing better scaling on multi-processors o many enhancements to the garbage collector o optional alternative TEXT implementation which promises better performance o restructured low-level code avoiding redundancies, making new ports easier to create and maintain > * Additional software suites: o CM3-IDE, the open source release of Critical Mass' Reactor (tm) product > o Caltech-parser > o Cvsup. > > * Miscellaneous: > o documentation: > - Manual pages for (cm3, quake, m3makefile, ...). o much improved debugging with m3gdb > Some selected historical improvements of CM3 over the > original DEC-SRC m3 compiler are: > > * Language enhancements: > o New primitive type > - WIDECHAR, and new widechar literal > o New pragmas: > - ASSERT, > - DEBUG, > - IMPLICIT. > > * Text may contain Unicode characters, > * Support for dynamically linked (shared) libraries. > > * The quake supporting scripting language is now embedded > within the compiler itself. > > We hope everyone tries this latest version of our Modula-3 compiler, > and associated library suite. > > The CM3 Modula-3 development team. > *** END CUT *** > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ Probably I've missed something; others may check and extend the list. 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 From rcoleburn at scires.com Wed Dec 2 23:17:55 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Dec 2009 17:17:55 -0500 Subject: [M3devel] threads are broken on Windows Message-ID: <4B16A059.1E75.00D7.1@scires.com> Something is wrong with threads on Windows from the HEAD branch. After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 2 23:21:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Dec 2009 17:21:49 -0500 Subject: [M3devel] threads are broken on Windows In-Reply-To: <4B16A059.1E75.00D7.1@scires.com> References: <4B16A059.1E75.00D7.1@scires.com> Message-ID: <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> Jay's call on that one... On 2 Dec 2009, at 17:17, Randy Coleburn wrote: > Something is wrong with threads on Windows from the HEAD branch. > > After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 > *** > > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 > 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 > 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 > 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 > 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 > 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Dec 2 23:47:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Dec 2009 17:47:37 -0500 Subject: [M3devel] Looking to update cm3 manual page. In-Reply-To: <538131.35719.qm@web56806.mail.re3.yahoo.com> References: <538131.35719.qm@web56806.mail.re3.yahoo.com> Message-ID: <4B16A74F.1E75.00D7.1@scires.com> Peter: We need to make sure to add information about cm3IDE. The users guide can be found at: m3-sys\cm3ide\UsersGuide\CM3_IDE_UsersGuide.pdf Some of the environment variables you describe have to do with cm3IDE. Here is a list: CM3_IDE_HOME = env var for root of home folder HOME = alternate home folder root, if CM3_IDE_HOME not supplied The following variables are expected to be defined in the CM3.CFG file: INITIAL_CM3_IDE_BROWSER = full path to the web browser that should be used with cm3IDE INITIAL_CM3_IDE_EDITOR = full path to the text editor that should be called by cm3IDE BUILD_DIR = NT386, HPPA, etc. PKG_USE = full path to the public package root, e.g. /cm3/pkg DOC_INSTALL = full path to the documentation root, e.g. /cm3/doc If the first 2 are not defined, cm3IDE will prompt user on command line to provide these the first time it is run. Thereafter, it saves the information in its config file that it places in the CM3_IDE_HOME folder. If the last 3 are not defined, cm3IDE tries to construct them using heuristics. If not successful, the program will abort. cm3IDE requires that is "examples" folder be located off the installation root, e.g., cm3/examples. If examples is not found, cm3IDE will still run, but it will not be able to offer up any examples. In an environment that allows spaces in filenames, such as Windows, you can run into problems if any of the paths defined in these variables have embedded spaces. On Windows, you can get around this problem by using the short 8.3 name equivalent. Regards, Randy >>> Peter Eiserloh 12/2/2009 12:01 PM >>> Hi all, It has been more than half a year since I last looked at the CM3 manual page. I am now looking at the it in preparation for the release of version 5.8, and noticing some deficiencies. I asking for help in identifying any further places it is lacking. I can integrate any feedback into a revised manual page, and submit an updated version back to the archives. Currently identified deficiencies: o The manual page should explicitly state which version of the compiler it documents. o The sub-section "Expected Directory Structure" needs a better discussion, especially an introduction. o The discussion of mode option "-ship" mentions environment variable CM3_INSTALL_ROOT, yet in cm3.cfg we set INSTALL_ROOT without the "CM3_" prefix. This should be resolved. ** What is the exact meaning of these two? Is one recognized by the compiler, and the other by the supporting quake code? o The ENVIRONMENT section does not mention CM3_INSTALL_ROOT at all. Add a discussion about both INSTALL_ROOT, and CM3_INSTALL_ROOT. ** Am I missing any other environment variables? o Missing command line options for the compiler: - I currently have "-g", but no discussion of -gstabs. No discussion about not supporting DWARF (or do we?). o Compiler unique language features, (i.e., pragmas). The reference books (Nelson, and Harbison) give a list of suggested pragmas. The manual page should list the ones supported by the CM3 compiler explicitly, and show their syntax. ** Can someone list for me the pragmas supported by the current (5.8.4) compiler. o Should list any limitations of either the compiler, or the library suite provided with the compiler. For example, the WIDECHAR is limited by its 16-bit size to only a portion of the unicode character set (the basic multi lingual plane), whereas a unicode character is 20-bits, and we would need either a 24-bit or 32-bit sized type to contain it all. ** Are there any other known limitations of the compiler, or library suite? - length of identifier? - length of TEXT (ie, memory) - length of filenames, or pathname (some architectures may have differences, ie MS-Windows). o There should be a discussion of the @m3XXX runtime library command line options. o There should be an EXAMPLE section, with example source code (Hello world), along with supporting m3makefile. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 01:18:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 00:18:20 +0000 Subject: [M3devel] threads are broken on Windows In-Reply-To: <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> References: <4B16A059.1E75.00D7.1@scires.com>, <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> Message-ID: That's wierd, but I do see it occuring too. Will look later. - Jay From: hosking at cs.purdue.edu Date: Wed, 2 Dec 2009 17:21:49 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] threads are broken on Windows Jay's call on that one... On 2 Dec 2009, at 17:17, Randy Coleburn wrote: Something is wrong with threads on Windows from the HEAD branch. After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 12:09:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 11:09:53 +0000 Subject: [M3devel] processing stack/context Message-ID: Tony, it looks like you assume the context passed to a signal handler is on the stack. Is that really guaranteed? It couldn't be in some thread local for some reason? (signals can nest? Therefore that would be problematic?) We can just use the address of a local, right? And we can assume the signal stack is the regular stack? By default? (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 3 16:05:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Dec 2009 10:05:33 -0500 Subject: [M3devel] processing stack/context In-Reply-To: References: Message-ID: <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Actually, in the latest version I explicitly process the signal context as well as the stack. On 3 Dec 2009, at 06:09, Jay K wrote: > Tony, it looks like you assume the context passed to a signal handler is on the stack. > Is that really guaranteed? It couldn't be in some thread local for some reason? > (signals can nest? Therefore that would be problematic?) > We can just use the address of a local, right? > > And we can assume the signal stack is the regular stack? > By default? > (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) > > I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 19:33:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 18:33:03 +0000 Subject: [M3devel] processing stack/context In-Reply-To: <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> References: , <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Message-ID: Tony, Understood, but you use the context as one end of the stack. void ThreadPThread__ProcessStopped (m3_pthread_t mt, char *bottom, char *context, void (*p)(void *start, void *limit)) { /* process stack */ if (stack_grows_down) { assert(context < bottom); p(context, bottom); here } else { assert(bottom < context); p(bottom, context); here } /* process register context */ p(context, context + sizeof(ucontext_t)); } - Jay From: hosking at cs.purdue.edu Date: Thu, 3 Dec 2009 10:05:33 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] processing stack/context Actually, in the latest version I explicitly process the signal context as well as the stack. On 3 Dec 2009, at 06:09, Jay K wrote: Tony, it looks like you assume the context passed to a signal handler is on the stack. Is that really guaranteed? It couldn't be in some thread local for some reason? (signals can nest? Therefore that would be problematic?) We can just use the address of a local, right? And we can assume the signal stack is the regular stack? By default? (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 3 20:02:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Dec 2009 14:02:34 -0500 Subject: [M3devel] processing stack/context In-Reply-To: References: , <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Message-ID: <9C163B67-026B-48CD-B6D0-1C54D7910166@cs.purdue.edu> Ah, yes, understood. I think in general one can assume that the signal handler context is on the actual stack (we are not using sigaltstack here), but yes it might be safer to explicitly extract a "top" value in the signal handler, independently of the context and pass it in as another parameter to ProcessStopped. 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 3 Dec 2009, at 13:33, Jay K wrote: > Tony, Understood, but you use the context as one end of the stack. > > void > ThreadPThread__ProcessStopped (m3_pthread_t mt, char *bottom, char *context, > void (*p)(void *start, void *limit)) > { > /* process stack */ > if (stack_grows_down) { > assert(context < bottom); > p(context, bottom); here > } else { > assert(bottom < context); > p(bottom, context); here > } > /* process register context */ > p(context, context + sizeof(ucontext_t)); > } > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 3 Dec 2009 10:05:33 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] processing stack/context > > Actually, in the latest version I explicitly process the signal context as well as the stack. > > On 3 Dec 2009, at 06:09, Jay K wrote: > > Tony, it looks like you assume the context passed to a signal handler is on the stack. > Is that really guaranteed? It couldn't be in some thread local for some reason? > (signals can nest? Therefore that would be problematic?) > We can just use the address of a local, right? > > And we can assume the signal stack is the regular stack? > By default? > (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) > > I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 22:20:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 21:20:32 +0000 Subject: [M3devel] ThreadWin32/LockMutex/giantLock/alertable? Message-ID: It'd be good to remove the giantLock from LockMutex/UnlockMutex. Mutexes can be replaced, like in Java, with just interlocked+semaphore -- no wait list (the semaphore would have an implicit wait list) -- or similarly just a Win32 critical section. I believe the inefficieny of ThreadWin32 having a "giantLock" need not impact folks only using locks -- it is only needed when acting on condition variables, and /possibly/ alert/alertwait (but probably not). In looking at it, something that bugs me is "act.alertable := FALSE". That can be outside the lock? Or remove entirely? And/or moved to before "RAISE Alerted"? Or for that matter, AlertWait should always exit with it false? And Wait should always assert it true? And there's some redundancy there. Basically, it should always be FALSE unless within AlertWait? I'm pretty sure those later options -- alertable is generally false, and writes only need to occur within AlertWait to make it temporarily true. LockMutex could just assert that it is false. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 10:00:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 09:00:27 +0000 Subject: [M3devel] FW: some open bugs In-Reply-To: <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 12:48:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 11:48:46 +0000 Subject: [M3devel] DateBsd.m3 lock usually not needed Message-ID: It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:06:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:06:45 +0000 Subject: [M3devel] some open bugs In-Reply-To: <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: In head: https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) doesn't occur jbook2:bin jay$ /cm3.amd64/bin/cm3 ? --- building in AMD64_DARWIN --- Fatal Error: unsupported file type "?" Perhaps should print usage. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Mixed. https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between doesn't occur There is this: m3-sys/windowsResources/AMD64_DARWIN/.M3SHIP seems to be broken: make_dir("/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib") symbolic_link_file("libwindowsResources.5.2.dylib", "/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib/libwindowsResources.dylib") symbolic_link_file("libwindowsResources.5.2.dylib", "/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib/libwindowsResources.5.dylib") Which I understand in general, haven't looked at it here. I'm not too blame for all the funny characters in "tmp". Apple does that. Need to test release. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: FW: some open bugs Date: Sun, 6 Dec 2009 09:00:27 +0000 > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:18:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:18:39 +0000 Subject: [M3devel] formsedit AMD64_DARWIN unslotted thread Message-ID: Tony, somtimes, like one in ten, starting up, AMD64_DARWIN, formsedit, head. Maybe worth trying a simpler AssignSlot? (gdb) r Starting program: /private/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-/cm3/bin/formsedit warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries +++++++++++++++++..... done *** *** runtime error: *** Thread client error: unslotted thread! *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 349 *** Program received signal SIGABRT, Aborted. 0x00007fff83416e3e in semaphore_wait_signal_trap () (gdb) thread apply all bt Thread 8 (process 54920 thread 0x2693): #0 0x00007fff834e06be in __semwait_signal_nocancel () #1 0x00007fff834e02f4 in nanosleep$NOCANCEL () #2 0x00007fff834da404 in usleep$NOCANCEL () #3 0x00007fff834eef77 in abort () #4 0x00000001009acbe1 in Cstdlib__abort () #5 0x00000001009a2eea in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #6 0x0000000100996e64 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #7 0x000000010099457d in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #8 0x0000000100994229 in RTError__Msg (M3_Bd56fi_file=0x1009f5fb0, M3_AcxOUs_line=349, M3_Bd56fi_msgA=0x1009f5ff0, M3_Bd56fi_msgB=0x1009f5b88, M3_Bd56fi_msgC=0x0) at ../src/runtime/common/RTError.m3:23 #9 0x00000001009a97fe in ThreadPThread__Die (M3_AcxOUs_lineno=349, M3_Bd56fi_msg=0x1009f5b88) at ../src/thread/PTHREAD/ThreadPThread.m3:1245 #10 0x00000001009a5fe1 in ThreadPThread__FreeSlot (M3_BXP32l_t=0x102259910) at ../src/thread/PTHREAD/ThreadPThread.m3:349 #11 0x00000001009a6b1c in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101635220) at ../src/thread/PTHREAD/ThreadPThread.m3:486 #12 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101635220) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #13 0x00007fff83444e8b in _pthread_start () #14 0x00007fff83444d4d in thread_start () Thread 7 (process 54920 thread 0x2707): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x10162c590, M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257210, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257210) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x00000001003b17fa in XMessenger__Messenger (M3_EVlqQO_self=0x1015d23a8) at ../src/xvbt/XMessenger.m3:69 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c590) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c590) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 6 (process 54920 thread 0x240b): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x10162c480, M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257250, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257250) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x00000001003c1167 in XInput__FilterXInput (M3_DSd60P_self=0x1015d2330) at ../src/xvbt/XInput.m3:102 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c480) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c480) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 5 (process 54920 thread 0x250b): #0 0x00007fff83462582 in select$DARWIN_EXTSN () #1 0x00000001009ab82d in Unix__select () #2 0x00000001009a7e88 in ThreadPThread__XIOWait__CallSelect.1153 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:677 #3 0x00000001009a7b20 in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:716 #4 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:619 #5 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x1015d22b8) at ../src/xvbt/XInput.m3:63 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 4 (process 54920 thread 0x2103): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5ef in ThreadPThread__pthread_cond_timedwait () #3 0x00000001009a72d9 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1016185f0, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:575 #4 0x00000001009a73b5 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:590 #5 0x0000000100075ab2 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:259 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 3 (process 54920 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 54920 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5ef in ThreadPThread__pthread_cond_timedwait () #3 0x00000001009a72d9 in ThreadPThread__XPause (M3_DMxDjQ_self=0x101618080, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:575 #4 0x00000001009a73b5 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:590 #5 0x00000001004090cf in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:460 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 54920 local thread 0x2e03): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a570d in ThreadPThread__AssignSlot (M3_BXP32l_t=0x1021cc0b0) at ../src/thread/PTHREAD/ThreadPThread.m3:301 #4 0x00000001009a6516 in ThreadPThread__CreateT (M3_DMxDjQ_act=0x1016353b0) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #5 0x00000001009a6b72 in Thread__Fork (M3_EMTrVz_closure=0x1015b1990) at ../src/thread/PTHREAD/ThreadPThread.m3:496 #6 0x000000010040a402 in VBTRep__Mark (M3_BFdKo9_v=0x1021fe380) at ../src/vbt/VBTRep.m3:587 #7 0x00000001003fcedf in VBT__Mark (M3_BFdKo9_v=0x1021fe380) at ../src/vbt/VBT.m3:1247 #8 0x000000010042ee00 in HVSplit__NewShape (M3_ABI5Rn_v=0x1021fe380, M3_BFdKo9_ch=0x1022002d8) at ../src/split/HVSplit.m3:487 #9 0x00000001003fcbd3 in VBT__NewShape (M3_BFdKo9_v=0x1022002d8) at ../src/vbt/VBT.m3:1225 #10 0x000000010007d2ad in FlexVBT__Rescreen (M3_BpJoz9_v=0x1022002d8, M3_BpW0LT_cd=0x7fff5fbfc800) at ../src/lego/FlexVBT.m3:101 #11 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1022002d8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #12 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fe380, M3_BpW0LT_cd=0x7fff5fbfc990) at ../src/vbt/VBTClass.m3:751 #13 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fe380, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #14 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fcbb8, M3_BpW0LT_cd=0x7fff5fbfcb20) at ../src/vbt/VBTClass.m3:751 #15 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fcbb8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #16 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fc018, M3_BpW0LT_cd=0x7fff5fbfcd20) at ../src/vbt/VBTClass.m3:751 #17 0x0000000100429b6d in BorderedVBT__Rescreen (M3_C4s4Wp_v=0x1021fc018, M3_BpW0LT_cd=0x7fff5fbfcd20) at ../src/split/BorderedVBT.m3:157 #18 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fc018, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #19 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb4e8, M3_BpW0LT_cd=0x7fff5fbfcee0) at ../src/vbt/VBTClass.m3:751 #20 0x000000010007d2a4 in FlexVBT__Rescreen (M3_BpJoz9_v=0x1021fb4e8, M3_BpW0LT_cd=0x7fff5fbfcee0) at ../src/lego/FlexVBT.m3:100 #21 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb4e8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #22 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa248, M3_BpW0LT_cd=0x7fff5fbfd070) at ../src/vbt/VBTClass.m3:751 #23 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa248, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #24 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb410, M3_BpW0LT_cd=0x7fff5fbfd230) at ../src/vbt/VBTClass.m3:751 #25 0x00000001000a675f in ShadowedVBT__Rescreen (M3_AyFi3t_v=0x1021fb410, M3_BpW0LT_cd=0x7fff5fbfd230) at ../src/lego/ShadowedVBT.m3:86 #26 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb410, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #27 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fbe00, M3_BpW0LT_cd=0x7fff5fbfd3c0) at ../src/vbt/VBTClass.m3:751 #28 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fbe00, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #29 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb330, M3_BpW0LT_cd=0x7fff5fbfd5c0) at ../src/vbt/VBTClass.m3:751 #30 0x0000000100429b6d in BorderedVBT__Rescreen (M3_C4s4Wp_v=0x1021fb330, M3_BpW0LT_cd=0x7fff5fbfd5c0) at ../src/split/BorderedVBT.m3:157 #31 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb330, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #32 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa160, M3_BpW0LT_cd=0x7fff5fbfd810) at ../src/vbt/VBTClass.m3:751 #33 0x0000000100451530 in StableVBT__Rescreen (M3_CStG2l_w=0x1021fa160, M3_BpW0LT_cd=0x7fff5fbfd810) at ../src/split/StableVBT.m3:115 #34 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa160, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #35 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa018, M3_BpW0LT_cd=0x7fff5fbfda00) at ../src/vbt/VBTClass.m3:751 #36 0x00000001000b2711 in ZChildVBT__Rescreen (M3_EF20wQ_v=0x1021fa018, M3_BpW0LT_cd=0x7fff5fbfda00) at ../src/lego/ZChildVBT.m3:127 #37 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa018, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #38 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1015aea90, M3_BpW0LT_cd=0x7fff5fbfdc10) at ../src/vbt/VBTClass.m3:751 #39 0x0000000100432804 in ZSplit__Rescreen (M3_COSw3M_v=0x1015aea90, M3_BpW0LT_cd=0x7fff5fbfdc10) at ../src/split/ZSplit.m3:235 #40 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1015aea90, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #41 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8970, M3_BpW0LT_cd=0x7fff5fbfddd0) at ../src/vbt/VBTClass.m3:751 #42 0x000000010007d2a4 in FlexVBT__Rescreen (M3_BpJoz9_v=0x1021f8970, M3_BpW0LT_cd=0x7fff5fbfddd0) at ../src/lego/FlexVBT.m3:100 #43 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8970, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #44 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8858, M3_BpW0LT_cd=0x7fff5fbfdf60) at ../src/vbt/VBTClass.m3:751 #45 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8858, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #46 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8770, M3_BpW0LT_cd=0x7fff5fbfe0f0) at ../src/vbt/VBTClass.m3:751 #47 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8770, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #48 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x101799158, M3_BpW0LT_cd=0x7fff5fbfe300) at ../src/vbt/VBTClass.m3:751 #49 0x0000000100432804 in ZSplit__Rescreen (M3_COSw3M_v=0x101799158, M3_BpW0LT_cd=0x7fff5fbfe300) at ../src/split/ZSplit.m3:235 #50 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x101799158, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #51 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1015b7918, M3_BpW0LT_cd=0x7fff5fbfe490) at ../src/vbt/VBTClass.m3:751 #52 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1015b7918, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #53 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b9858, M3_BpW0LT_cd=0x7fff5fbfe650) at ../src/vbt/VBTClass.m3:751 #54 0x0000000100469d11 in InstalledVBT__Rescreen (M3_BnDICA_v=0x1024b9858, M3_BpW0LT_cd=0x7fff5fbfe650) at ../src/trestle/InstalledVBT.m3:77 #55 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b9858, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #56 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b9948, M3_BpW0LT_cd=0x7fff5fbfe8a0) at ../src/vbt/VBTClass.m3:751 #57 0x0000000100451530 in StableVBT__Rescreen (M3_CStG2l_w=0x1024b9948, M3_BpW0LT_cd=0x7fff5fbfe8a0) at ../src/split/StableVBT.m3:115 #58 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b9948, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #59 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b97a0, M3_BpW0LT_cd=0x7fff5fbfea80) at ../src/vbt/VBTClass.m3:751 #60 0x000000010045342f in JoinedVBT__Rescreen (M3_B2daE0_v=0x1024b97a0, M3_BpW0LT_cd=0x7fff5fbfea80) at ../src/split/JoinedVBT.m3:169 #61 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b97a0, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #62 0x0000000100457e68 in JoinParent__Be (M3_EjiMte_prntP=0x1024a08d0, M3_B2daE0_v=0x1024b97a0) at ../src/split/JoinParent.m3:309 #63 0x0000000100467485 in DpyFilter__Init (M3_AMerq9_v=0x1024a08d0, M3_B2daE0_ch=0x1024b97a0, M3_AicXUJ_enabled=1 '\001') at ../src/trestle/DpyFilter.m3:59 #64 0x00000001004699e1 in InstalledVBT__InitParent (M3_DaeRwb_res=0x1024a08d0, M3_Bli4Mk_ch=0x1024b97a0) at ../src/trestle/InstalledVBT.m3:49 #65 0x000000010046cee9 in Trestle__AddApp (M3_D5sYfW_a=0x1024a0878, M3_Arkhkf_cuser=0x1015d2460) at ../src/trestle/Trestle.m3:402 #66 0x000000010046c1a9 in Trestle__NoConfInit (M3_D5sYfW_a=0x1024a0878, M3_Arkhkf_u=0x1015d2460) at ../src/trestle/Trestle.m3:317 #67 0x000000010046caf1 in Trestle__InnerAttach (M3_BFdKo9_v=0x1015b7918, M3_DpX0S5_trsl=0x102256b38) at ../src/trestle/Trestle.m3:379 #68 0x000000010046c17b in Trestle__Attach (M3_BFdKo9_v=0x1015b7918, M3_DpX0S5_trsl=0x102256b38) at ../src/trestle/Trestle.m3:285 #69 0x0000000100008c58 in FormsEditVBT__Install (M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_editorGeo=0x100163230) at ../src/FormsEditVBT.m3:379 #70 0x0000000100007371 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:255 #71 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #72 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #73 0x000000010099385e in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #74 0x0000000100992ba2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #75 0x0000000100992c40 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #76 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff858, envp=0x7fff5fbff868) at _m3main.mc:4 (gdb) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 15:25:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 09:25:58 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: Message-ID: That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... 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 6 Dec 2009, at 06:48, Jay K wrote: > It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:29:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:29:29 +0000 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: , Message-ID: I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while switching is disabled? I came up with something a bit hacky but maybe ok. - Jay Subject: Re: [M3devel] DateBsd.m3 lock usually not needed From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 09:25:58 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... 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 On 6 Dec 2009, at 06:48, Jay K wrote:It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:31:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:31:13 +0000 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up Message-ID: formsedit startup seems to often hang in the debugger, in head. The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) (gdb) thread apply all bt Thread 7 (process 56120 thread 0x250b): #0 0x00007fffffe0027d in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 6 (process 56120 thread 0x240b): #0 0x00007fffffe00278 in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 5 (process 56120 thread 0x2707): #0 0x00007fffffe00296 in ?? () #1 0x00007fff83447ec2 in _pthread_lookup_thread () #2 0x00007fff83447e73 in pthread_mach_thread_np () #3 0x00000001009aa770 in ThreadPThread__SuspendThread () #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #18 0x00007fff83444e8b in _pthread_start () #19 0x00007fff83444d4d in thread_start () Thread 4 (process 56120 thread 0x2103): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #9 0x00007fff83444e8b in _pthread_start () #10 0x00007fff83444d4d in thread_start () Thread 3 (process 56120 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 56120 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 56120 local thread 0x2e03): #0 0x00007fff83444c48 in pthread_create () #1 0x00000001009aa2eb in ThreadPThread__thread_create () #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 (gdb) cont Continuing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 6 15:37:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Dec 2009 15:37:00 +0100 Subject: [M3devel] Hudson failures and outages, was: RE: solsun/solgnu In-Reply-To: References: , <20091129175131.3a9yckela8cgck0c@mail.elegosoft.com> Message-ID: <20091206153700.m98zvhh3dwwo04go@mail.elegosoft.com> Quoting Jay K : > There was also a problem with SOLgnu where a bad cm3 had been built > and gotten "stuck". > I cleaned up the various directories in the workspace and got it > working again. > (There's no evidence trail.) Great, thanks. I've had a more or less complete server crash here at home and had to get a new machine. I'm still busy reinstalling and recovering. Unfortunately, this is now also the step from 32 to 64 bits for my server, and most of the old programs/setups don't work out of the box. I'll probably need several more days until everything is in working order again. So luthien will probably not be available for FreeBSD4 builds. The good news is that I can now test the AMD64_FREEBSD stuff :-) 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 From jay.krell at cornell.edu Sun Dec 6 15:48:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:48:22 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head Message-ID: Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:51:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:51:34 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: Message-ID: I also saw I386_DARWIN Juno FreeSlot: z=0x2141c94 t=0xb038ced0 n_slotted=7 slots=0xb7909c t.act=0x22b8010 t.act.slot=14 *** *** runtime error: *** Thread client error: unslotted thread! *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 364 *** What I'll probably do over the next few days is test more PPC_DARWIN, LINUXLIBC6, Solaris, maybe some BSD, see where it occurs. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 6 Dec 2009 14:48:22 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:14:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:14:14 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: , Message-ID: <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> On 6 Dec 2009, at 09:29, Jay K wrote: > I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while > switching is disabled? Yes, it sure can. DisableSwitching/EnableSwitching is exactly what is needed whenever you are dealing with libraries that are not thread safe with the user-level thread-switching. > I came up with something a bit hacky but maybe ok. > > - Jay > > > Subject: Re: [M3devel] DateBsd.m3 lock usually not needed > From: hosking at cs.purdue.edu > Date: Sun, 6 Dec 2009 09:25:58 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... > > 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 6 Dec 2009, at 06:48, Jay K wrote: > > It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:16:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:16:51 -0500 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up In-Reply-To: References: Message-ID: Maybe related to the FreeSlot problem I just fixed? Please try with the latest. On 6 Dec 2009, at 09:31, Jay K wrote: > formsedit startup seems to often hang in the debugger, in head. > > The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. > I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) > > (gdb) thread apply all bt > > Thread 7 (process 56120 thread 0x250b): > #0 0x00007fffffe0027d in ?? () > #1 0x00007fff83444db7 in _pthread_start () > #2 0x00007fff83444d4d in thread_start () > > Thread 6 (process 56120 thread 0x240b): > #0 0x00007fffffe00278 in ?? () > #1 0x00007fff83444db7 in _pthread_start () > #2 0x00007fff83444d4d in thread_start () > > Thread 5 (process 56120 thread 0x2707): > #0 0x00007fffffe00296 in ?? () > #1 0x00007fff83447ec2 in _pthread_lookup_thread () > #2 0x00007fff83447e73 in pthread_mach_thread_np () > #3 0x00000001009aa770 in ThreadPThread__SuspendThread () > #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 > #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 > #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 > #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 > #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 > #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 > #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 > #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 > #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 > #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 > #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 > #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 > #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #18 0x00007fff83444e8b in _pthread_start () > #19 0x00007fff83444d4d in thread_start () > > Thread 4 (process 56120 thread 0x2103): > #0 0x00007fff83416e3e in semaphore_wait_signal_trap () > #1 0x00007fff8341e758 in pthread_mutex_lock () > #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () > #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 > #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 > #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 > #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 > #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #9 0x00007fff83444e8b in _pthread_start () > #10 0x00007fff83444d4d in thread_start () > > Thread 3 (process 56120 thread 0x2003): > #0 0x00007fff8341ddc2 in __semwait_signal () > #1 0x00007fff83445ca9 in _pthread_cond_wait () > #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () > #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 > #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #8 0x00007fff83444e8b in _pthread_start () > #9 0x00007fff83444d4d in thread_start () > > Thread 2 (process 56120 thread 0x313): > #0 0x00007fff8341ddc2 in __semwait_signal () > #1 0x00007fff83445ca9 in _pthread_cond_wait () > #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () > #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 > #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #8 0x00007fff83444e8b in _pthread_start () > #9 0x00007fff83444d4d in thread_start () > > Thread 1 (process 56120 local thread 0x2e03): > #0 0x00007fff83444c48 in pthread_create () > #1 0x00000001009aa2eb in ThreadPThread__thread_create () > #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 > #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 > #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 > #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 > #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 > #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 > #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 > #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 > #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 > #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 > #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 > #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 > #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 > #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 > (gdb) cont > Continuing. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:23:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:23:33 -0500 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: Message-ID: Please report back how things behave with the latest commit... On 6 Dec 2009, at 09:48, Jay K wrote: > Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). > > Here is the second crash > > (gdb) r > Starting program: /Users/jay/cm3/bin/Juno > Reading symbols for shared libraries +++++++++++++++++++++++..... done > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 > [Switching to process 79884 thread 0x29b7] > 0x01710774 in ?? () > (gdb) bt > #0 0x01710774 in ?? () > #1 0xb038cf28 in ?? () > Previous frame inner to this frame (gdb could not unwind past this frame) > (g > > > (gdb) thread apply all bt > > Thread 9 (process 79884 thread 0x27bf): > #0 0x968782ce in semaphore_wait_signal_trap () > #1 0x9687fda5 in pthread_mutex_lock () > #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () > #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 > #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 > #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 > #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #7 0x968a9155 in _pthread_start () > #8 0x968a9012 in thread_start () > > Thread 8 (process 79884 thread 0x29b7): > #0 0x01710774 in ?? () > #1 0xb038cf28 in ?? () > Previous frame inner to this frame (gdb could not unwind past this frame) > > Thread 7 (process 79884 thread 0x2603): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 6 (process 79884 thread 0x2507): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 5 (process 79884 thread 0x240f): > #0 0x968c76fa in select$DARWIN_EXTSN () > #1 0x00b524c3 in Unix__select () > #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 > #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 > #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 > #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 > #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #8 0x968a9155 in _pthread_start () > #9 0x968a9012 in thread_start () > > Thread 4 (process 79884 thread 0x2303): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () > #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () > #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 > #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 > #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 3 (process 79884 thread 0x2203): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 2 (process 79884 thread 0x1003): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () > #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () > #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 > #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 > #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 1 (process 79884 local thread 0x2e03): > #0 0x968782ce in semaphore_wait_signal_trap () > #1 0x9687fda5 in pthread_mutex_lock () > #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () > #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 > #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 > #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 > #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 > #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 > #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 > #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 > #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 > #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 > #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 > #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 > #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 > #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:54:46 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:54:46 -0500 Subject: [M3devel] FW: some open bugs In-Reply-To: References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: <4B1C34ED.1E75.00D7.1@scires.com> Hi Jay: Can you be more specific about the nature of the "windows C runtime version issue" you report below ? Regards, Randy >>> Jay K 12/6/2009 4:00 AM >>> > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:57:02 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:57:02 -0500 Subject: [M3devel] build problem diagnosis in caltech-parser test package References: <4B150A90020000D700067FB8@scires.com> Message-ID: <4B1C3575.1E75.00D7.1@scires.com> I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:59:15 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:59:15 -0500 Subject: [M3devel] Fwd: [M3commit] CVS Update: cm3 References: <20091201165512.EA71F2474001@birch.elegosoft.com> Message-ID: <4B1C35FA.1E75.00D7.1@scires.com> Is everyone ok with the edit I made here? If so, someone should promote this fix to the release branch. Also, Is there a reason we should limit this package to POSIX platforms? If not, we should take out the if statement at line 31 and the corresponding end. --Randy >>> Randy Coleburn 12/1/2009 5:55 PM >>> CVSROOT:/usr/cvs Changes by:rcoleburn at birch.09/12/01 17:55:12 Modified files: cm3/m3-tools/cvsup/suplib/src/: m3makefile Log message: add missing "end" statement at line 58 to correct compile-time syntax error. Someone needs to check me on this one. After this change, I don't get any packages built in cvsup on WindowsXP, I suppose due to some prerequiste not being met. But at least I don't get the syntax error. Not sure why the package m3makefile seems to be limited to POSIX platforms at line 31. Everything was building on Windows before.--R.Coleburn Here is the compiler output before my correction: C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES "C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args", line 5: quake runtime error: C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\src\m3makefile, line 263: syntax error: "end" or "else" expected after "if" --procedure-- -line- -file--- include_dir -- 5 C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.03 2 removing temporary files 0.03 other --------------------------------------------------- 0.06 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:44:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:44:02 +0000 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up In-Reply-To: References: , Message-ID: Yes better now thank you. - Jay Subject: Re: AMD64_DARWIN head formsedit sometimes hangs starting up From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 14:16:51 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Maybe related to the FreeSlot problem I just fixed? Please try with the latest. On 6 Dec 2009, at 09:31, Jay K wrote:formsedit startup seems to often hang in the debugger, in head. The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) (gdb) thread apply all bt Thread 7 (process 56120 thread 0x250b): #0 0x00007fffffe0027d in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 6 (process 56120 thread 0x240b): #0 0x00007fffffe00278 in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 5 (process 56120 thread 0x2707): #0 0x00007fffffe00296 in ?? () #1 0x00007fff83447ec2 in _pthread_lookup_thread () #2 0x00007fff83447e73 in pthread_mach_thread_np () #3 0x00000001009aa770 in ThreadPThread__SuspendThread () #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #18 0x00007fff83444e8b in _pthread_start () #19 0x00007fff83444d4d in thread_start () Thread 4 (process 56120 thread 0x2103): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #9 0x00007fff83444e8b in _pthread_start () #10 0x00007fff83444d4d in thread_start () Thread 3 (process 56120 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 56120 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 56120 local thread 0x2e03): #0 0x00007fff83444c48 in pthread_create () #1 0x00000001009aa2eb in ThreadPThread__thread_create () #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 (gdb) cont Continuing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:44:46 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: , Message-ID: Yes better. I think I had actually fixed it. The other problem was something related to pthread_self vs. the handle you get from pthread_create or something..I don't understand that part. - Jay Subject: Re: I386_DARWIN Juno crash/hang head From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 14:23:33 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Please report back how things behave with the latest commit... On 6 Dec 2009, at 09:48, Jay K wrote:Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:55:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:55:08 +0000 Subject: [M3devel] race condition setting act.handle? Message-ID: pthread_create(act.handle) followed at some point by use of act.handle in the new thread. Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. What is to cause act.handle to be stored before the new thread starts and uses act.handle? For this reason in Win32 I create the thread suspended, store the handle, resume the thread. Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 7 10:29:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Dec 2009 10:29:00 +0100 Subject: [M3devel] Fwd: [M3commit] CVS Update: cm3 In-Reply-To: <4B1C35FA.1E75.00D7.1@scires.com> References: <20091201165512.EA71F2474001@birch.elegosoft.com> <4B1C35FA.1E75.00D7.1@scires.com> Message-ID: <20091207102900.gohdo855sg8scw0g@mail.elegosoft.com> Quoting Randy Coleburn : > Is everyone ok with the edit I made here? If so, someone should > promote this fix to the release branch. > Also, Is there a reason we should limit this package to POSIX platforms? > If not, we should take out the if statement at line 31 and the > corresponding end. AFAIK CVSup never had any support for Windows platforms. For its optimizations it relies heavily on very Unix-specific functions. I'm not aware that this has changed, but could be wrong. If you find that subsets of the packages compile, we can surely add them for Windows targets, too. Olaf > --Randy > >>>> Randy Coleburn 12/1/2009 5:55 PM >>> > CVSROOT:/usr/cvs > Changes by:rcoleburn at birch.09/12/01 17:55:12 > > Modified files: > cm3/m3-tools/cvsup/suplib/src/: m3makefile > > Log message: > add missing "end" statement at line 58 to correct compile-time syntax error. > > Someone needs to check me on this one. After this change, I don't > get any packages built in cvsup on WindowsXP, I suppose due to some > prerequiste not being met. But at least I don't get the syntax error. > > Not sure why the package m3makefile seems to be limited to POSIX > platforms at line 31. Everything was building on Windows > before.--R.Coleburn > > Here is the compiler output before my correction: > > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib>cm3 -verbose > EVAL ("C:\cm3\bin\cm3.cfg") > --- building in NT386 --- > > cd NT386 > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > EVAL ("m3make.args") > rm .M3SHIP > rm .M3OVERRIDES > "C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args", line > 5: quake runtime error: > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\src\m3makefile, line 263: > syntax error: "end" or "else" expected after "if" > > --procedure-- -line- -file--- > include_dir -- > 5 C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args > > Fatal Error: package build failed > > seconds #times operation > 0.03 2 removing temporary files > 0.03 other > --------------------------------------------------- > 0.06 TOTAL > > rm m3make.args > cd .. > > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib> > > -- 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 From peter.mckinna at gmail.com Mon Dec 7 12:17:50 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 7 Dec 2009 22:17:50 +1100 Subject: [M3devel] AutoFlushWr race. Message-ID: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> Hi, I thought I would have a try at fixing the problem in AutoFlushWr with the little program below. Alas I couldnt get a grip on it so maybe you guys could shed some light. This was with RC4 and on an amd64 linux box. It invariably crashes in FileWr.Seek where some invariant seems to be awry so obviously the worker thread created in AutoFlushWr is hitting or causing a race condition. Probably easily fixed. The thing that intrigued me was that most of the time running it did not cause the normal crash sequence and I had to ctrl-c to get back to the bash prompt which judging from the stack trace something in the threads area is amiss. Regards Peter MODULE Main; IMPORT FileWr,Wr,Rd,AutoFlushWr,Stdio,IO,Fmt,Thread; VAR myout := NEW(AutoFlushWr.T).init(Stdio.stdout); BEGIN FOR i := 0 TO 10000 DO Wr.PutText(myout,Fmt.Int(i) & "\n"); END; (* Thread.Pause(1.0D0); IO.Put("hit enter to end\n"); *) EVAL Rd.GetChar(Stdio.stdin); END Main. ... some iterations and 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) thread apply all bt Thread 3 (Thread 1106278736 (LWP 5197)): #0 0x00007f1a8b9ead29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f1a8bef8d4f in ThreadPThread__pthread_cond_wait (cond=0x24d0170, mutex=0x24d0770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007f1a8bef1ce0 in XWait (self=16_00000000024f2a48, m=16_00000000024ef030, c=16_00000000024ef0b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007f1a8bef214d in Wait (m=16_00000000024ef030, c=16_00000000024ef0b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007f1a8c9e2c62 in Worker (cl=16_00000000024f2a38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007f1a8bef4447 in RunThread (me=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007f1a8bef4140 in ThreadBase (param=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007f1a8b9e6fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007f1a8b75c5ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 139752010405600 (LWP 5194)): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 ---Type to continue, or q to quit--- #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () Thread 1 (LWP 5194): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= ---Type to continue, or q to quit--- RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) Now why is the stack trace duplicated for Thread 1 and Thread 2 and also why is there that last line #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 in the last frame? The first and last frame are duplicated. Havent seen it in other stack traces. Maybe something wrong with my setup? running once more we get ....... some iterations 4311 4312 4313 4314 4315 4316 4317 4318 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** OK here I had to ctrl-c it since it is hung ^C Program received signal SIGINT, Interrupt. 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 (m3gdb) thread apply all bt Thread 3 (Thread 1113143632 (LWP 5200)): #0 0x00007fd82e654d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007fd82eb62d4f in ThreadPThread__pthread_cond_wait (cond=0x19a9170, mutex=0x19a9770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007fd82eb5bce0 in XWait (self=16_00000000019caa48, m=16_00000000019c7030, c=16_00000000019c70b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007fd82eb5c14d in Wait (m=16_00000000019c7030, c=16_00000000019c70b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007fd82f64cc62 in Worker (cl=16_00000000019caa38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007fd82eb5e447 in RunThread (me=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007fd82eb5e140 in ThreadBase (param=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007fd82e650fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007fd82e3c65ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 140566490150624 (LWP 5198)): #0 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007fd82e652bf0 in _L_lock_102 () from /lib/libpthread.so.0 ../../gdb/gdb/dwarf2-frame.c:490: internal-error: Unknown CFI encountered. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Is this a problem with m3gdb? Running this program without the debugger more likely than not will produce a hung program, so I suspect some threading problem. That lll_lock_wait is definitely suspicious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:36:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:36:02 +0000 Subject: [M3devel] AutoFlushWr race. In-Reply-To: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> References: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> Message-ID: Thank you for looking into stuff Peter. We really need more help. Can you try again either with head or the release commit I just did? Thanks. See: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw/AutoFlushWr.m3 etc. Thanks, - Jay Date: Mon, 7 Dec 2009 22:17:50 +1100 From: peter.mckinna at gmail.com To: m3devel at elegosoft.com Subject: [M3devel] AutoFlushWr race. Hi, I thought I would have a try at fixing the problem in AutoFlushWr with the little program below. Alas I couldnt get a grip on it so maybe you guys could shed some light. This was with RC4 and on an amd64 linux box. It invariably crashes in FileWr.Seek where some invariant seems to be awry so obviously the worker thread created in AutoFlushWr is hitting or causing a race condition. Probably easily fixed. The thing that intrigued me was that most of the time running it did not cause the normal crash sequence and I had to ctrl-c to get back to the bash prompt which judging from the stack trace something in the threads area is amiss. Regards Peter MODULE Main; IMPORT FileWr,Wr,Rd,AutoFlushWr,Stdio,IO,Fmt,Thread; VAR myout := NEW(AutoFlushWr.T).init(Stdio.stdout); BEGIN FOR i := 0 TO 10000 DO Wr.PutText(myout,Fmt.Int(i) & "\n"); END; (* Thread.Pause(1.0D0); IO.Put("hit enter to end\n"); *) EVAL Rd.GetChar(Stdio.stdin); END Main. ... some iterations and 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) thread apply all bt Thread 3 (Thread 1106278736 (LWP 5197)): #0 0x00007f1a8b9ead29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f1a8bef8d4f in ThreadPThread__pthread_cond_wait (cond=0x24d0170, mutex=0x24d0770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007f1a8bef1ce0 in XWait (self=16_00000000024f2a48, m=16_00000000024ef030, c=16_00000000024ef0b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007f1a8bef214d in Wait (m=16_00000000024ef030, c=16_00000000024ef0b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007f1a8c9e2c62 in Worker (cl=16_00000000024f2a38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007f1a8bef4447 in RunThread (me=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007f1a8bef4140 in ThreadBase (param=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007f1a8b9e6fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007f1a8b75c5ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 139752010405600 (LWP 5194)): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 ---Type to continue, or q to quit--- #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () Thread 1 (LWP 5194): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= ---Type to continue, or q to quit--- RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) Now why is the stack trace duplicated for Thread 1 and Thread 2 and also why is there that last line #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 in the last frame? The first and last frame are duplicated. Havent seen it in other stack traces. Maybe something wrong with my setup? running once more we get ....... some iterations 4311 4312 4313 4314 4315 4316 4317 4318 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** OK here I had to ctrl-c it since it is hung ^C Program received signal SIGINT, Interrupt. 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 (m3gdb) thread apply all bt Thread 3 (Thread 1113143632 (LWP 5200)): #0 0x00007fd82e654d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007fd82eb62d4f in ThreadPThread__pthread_cond_wait (cond=0x19a9170, mutex=0x19a9770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007fd82eb5bce0 in XWait (self=16_00000000019caa48, m=16_00000000019c7030, c=16_00000000019c70b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007fd82eb5c14d in Wait (m=16_00000000019c7030, c=16_00000000019c70b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007fd82f64cc62 in Worker (cl=16_00000000019caa38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007fd82eb5e447 in RunThread (me=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007fd82eb5e140 in ThreadBase (param=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007fd82e650fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007fd82e3c65ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 140566490150624 (LWP 5198)): #0 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007fd82e652bf0 in _L_lock_102 () from /lib/libpthread.so.0 ../../gdb/gdb/dwarf2-frame.c:490: internal-error: Unknown CFI encountered. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Is this a problem with m3gdb? Running this program without the debugger more likely than not will produce a hung program, so I suspect some threading problem. That lll_lock_wait is definitely suspicious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:48:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:48:15 +0000 Subject: [M3devel] race condition setting act.handle? Message-ID: I think I resolved this in a simple efficient manner. Please take a look. Perhaps pthread_create is guaranteed to write back the pthread_t before the code runs though? Win32 isn't as amenable to the efficiency here due to the division between handles and thread ids. pthread I'm not really so familiar with, not sure of the efficiency. In particular, where pthreads has pthread_self(), Win32 has three analogs: GetCurrentThreadId() GetCurrentThread() DuplicateHandle(GetCurrentThread()...) GetCurrentThread and GetCurrentThreadId are both fast -- no kernel call. However you can't do all that much with their results, e.g. you can't Suspend/Resume/Close/Wait. GetCurrentThread returns a special /constant/ that always means the current thread, relative to the caller. DuplicateHandle(GetCurrentThread()...) gives you something you can Suspend/Resume/Close/Wait but of course is slower, a kernel call. I have to pay for either the DuplicateHandle or ResumeThread, a wash. pthreads just has the one pthread_self. Fast? I don't know. A kernel call? I don't know. Usable with suspend/resume (np)? Yes. Well on Solaris it is fast: -bash-3.00$ /usr/ccs/bin/dis -F pthread_self /usr/lib/libc.so disassembly for /usr/lib/libc.so thr_self() thr_self: 81 c3 e0 08 retl thr_self+0x4: d0 01 e0 98 ld [%g7 + 0x98], %o0 Recent Linux/x86 is fast: objdump -d /usr/lib/libpthread_a 00001020 <__pthread_self>: 1020: 55 push %ebp 1021: 89 e5 mov %esp,%ebp 1023: 65 a1 50 00 00 00 mov %gs:0x50,%eax 1029: 5d pop %ebp 102a: c3 ret 102b: 90 nop 102c: 8d 74 26 00 lea 0x0(%esi),%esi (geez though, six instructions where only two are needed, crazy..imagine if all code was unoptimal by that factor...) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Subject: race condition setting act.handle? Date: Mon, 7 Dec 2009 06:55:08 +0000 pthread_create(act.handle) followed at some point by use of act.handle in the new thread. Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. What is to cause act.handle to be stored before the new thread starts and uses act.handle? For this reason in Win32 I create the thread suspended, store the handle, resume the thread. Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:49:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:49:40 +0000 Subject: [M3devel] truncation test Message-ID: truncation test. There is content after this line but I bet it won't show. . I bet this won't show up. Let's see. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:49:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:49:00 +0000 Subject: [M3devel] AutoFlushWr race. In-Reply-To: References: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com>, Message-ID: We're still getting emails truncated. Thank you for looking into stuff Peter. We really need more help. Can you try again either with head or the release commit I just did? Thanks. See: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw/AutoFlushWr.m3 etc. Thanks, - Jay > From: jay.krell at cornell.edu > To: peter.mckinna at gmail.com; m3devel at elegosoft.com > Date: Mon, 7 Dec 2009 12:36:02 +0000 > Subject: Re: [M3devel] AutoFlushWr race. > > > Thank you for looking into stuff Peter. We really need more help. > > Can you try again either with head or the release commit I just did? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:04:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:04:30 +0000 Subject: [M3devel] (please ignore, sorry, there will be a few of these) truncation test (65) Message-ID: (please ignore, sorry, there will be a few of these) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:56 +0000 Subject: [M3devel] truncation test (70) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:29 +0000 Subject: [M3devel] truncation test (66) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:04 +0000 Subject: [M3devel] truncation test (65b) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:06:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:06:34 +0000 Subject: [M3devel] truncation test (74) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 123456789012345678901234567890123456789012345678901234567890123456789012345 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:07:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:07:03 +0000 Subject: [M3devel] truncation test (76) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:08:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:08:11 +0000 Subject: [M3devel] truncation test (75) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:09:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:09:30 +0000 Subject: [M3devel] truncation test (77) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:10:55 +0000 Subject: [M3devel] truncation test (80) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:15:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:15:21 +0000 Subject: [M3devel] m3devel email truncation Message-ID: Here are two ways to get email truncated: 1) have a line that contains only a period; I noticed that happened to Tony not long ago, and I can make it happen deliberately. 2) Have a period in column 76. It happened to me in an email about autoflush and I can also make that happen deliberately. Beyond column 76 is ok. Olaf had mentioned it being something about periods. Perhaps I should be sure to yell! or be uncertain? :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:35:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:35:06 +0000 Subject: [M3devel] build problem diagnosis in caltech-parser test package In-Reply-To: <4B1C3575.1E75.00D7.1@scires.com> References: <4B150A90020000D700067FB8@scires.com>, <4B1C3575.1E75.00D7.1@scires.com> Message-ID: Randy, There is a recurring pattern in the tree related to this. Buildlocal (with overrides) should use the unshipped binary. Because nothing is being shipped. buildship (without overrides) should use the shipped binary. Because things are being shipped right after they are built, or you are using already shipped stuff -- same thing really. (All tools need to be built standalone, in order for the buildlocal version to work. Depending -- $ORIGIN is not compatible with running unshipped binaries. Using full paths is, but requires knowing the paths at link time and linking differently depending on if you are going to run from build_dir or installdir.) To see this in action, search for "override" in *tmpl files. stubgen for example works this. This is probably something that needs more automatic handling? See here: C:\dev2\cm3.2\m3-comm\netobj\src\netobj-ov.tmpl C:\dev2\cm3.2\m3-comm\netobj\src\netobj.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj-ov.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj.tmpl and then very important: C:\dev2\cm3.2\m3-comm\sharedobj\src\m3overrides C:\dev2\cm3.2\m3-comm\netobj\src\m3overrides I have a strong suspicion as well that sharedobj\src\m3overrides and netobj\src\m3overrides should be included in the central m3overrides. (and a strong suspicion as well, as I've said, that this mechanism is flawed; a better implementation I suspect is to /always/ ship, but either on top of the running system, or not to the running system, and then if "not to the running system" passes tests, swap them or move the one to the other, etc.) - Jay Date: Sun, 6 Dec 2009 22:57:02 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problem diagnosis in caltech-parser test package I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Mon Dec 7 14:41:38 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Mon, 07 Dec 2009 14:41:38 +0100 Subject: [M3devel] m3devel email truncation In-Reply-To: References: Message-ID: <20091207144138.u5xm8nkwkk4scogg@mail.elegosoft.com> Ok, thanks, I'll look into it. Mike Quoting Jay K : > > Here are two ways to get email truncated: > > > > 1) have a line that contains only a period; I noticed that > > happened to Tony not long ago, and I can make it happen deliberately. > > > > 2) Have a period in column 76. > > It happened to me in an email about autoflush and I can also > > make that happen deliberately. Beyond column 76 is ok. > > > > Olaf had mentioned it being something about periods. > > > > Perhaps I should be sure to yell! or be uncertain? :) > > > > - Jay > > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Dec 7 15:17:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 14:17:46 +0000 Subject: [M3devel] build problem diagnosis in caltech-parser test package In-Reply-To: References: <4B150A90020000D700067FB8@scires.com>, <4B1C3575.1E75.00D7.1@scires.com>, Message-ID: I guess I should point out that cm3, cm3cg, mklib, the config files are all handled "incorrectly" here. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 7 Dec 2009 13:35:06 +0000 Subject: Re: [M3devel] build problem diagnosis in caltech-parser test package Randy, There is a recurring pattern in the tree related to this. Buildlocal (with overrides) should use the unshipped binary. Because nothing is being shipped. buildship (without overrides) should use the shipped binary. Because things are being shipped right after they are built, or you are using already shipped stuff -- same thing really. (All tools need to be built standalone, in order for the buildlocal version to work. Depending -- $ORIGIN is not compatible with running unshipped binaries. Using full paths is, but requires knowing the paths at link time and linking differently depending on if you are going to run from build_dir or installdir.) To see this in action, search for "override" in *tmpl files. stubgen for example works this. This is probably something that needs more automatic handling? See here: C:\dev2\cm3.2\m3-comm\netobj\src\netobj-ov.tmpl C:\dev2\cm3.2\m3-comm\netobj\src\netobj.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj-ov.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj.tmpl and then very important: C:\dev2\cm3.2\m3-comm\sharedobj\src\m3overrides C:\dev2\cm3.2\m3-comm\netobj\src\m3overrides I have a strong suspicion as well that sharedobj\src\m3overrides and netobj\src\m3overrides should be included in the central m3overrides. (and a strong suspicion as well, as I've said, that this mechanism is flawed; a better implementation I suspect is to /always/ ship, but either on top of the running system, or not to the running system, and then if "not to the running system" passes tests, swap them or move the one to the other, etc.) - Jay Date: Sun, 6 Dec 2009 22:57:02 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problem diagnosis in caltech-parser test package I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 7 15:27:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Dec 2009 15:27:14 +0100 Subject: [M3devel] m3devel email truncation In-Reply-To: References: Message-ID: <20091207152714.rt753229gkww4ccc@mail.elegosoft.com> Quoting Jay K : > Here are two ways to get email truncated: > > 1) have a line that contains only a period; I noticed that > > happened to Tony not long ago, and I can make it happen deliberately. > > 2) Have a period in column 76. > > It happened to me in an email about autoflush and I can also > make that happen deliberately. Beyond column 76 is ok. > > Olaf had mentioned it being something about periods. A period alone on a line is an ancient convention for EOF (from the ages when terminals with serial lines connected via 2400 or 9600 baud were in common use). The mail servers here at NSN do the same thing still (ignore everything after a period :-). I don't think it is required by any standard (though I'm not sure here), and I assume it is buried deep in one of our filters/scripts/scanners which process the mails. So it may not be easy to locate. I'm not sure why column 76 should be special, though one could assume that's where wrapping text occurs so that the period is in column one on the next line. > Perhaps I should be sure to yell! or be uncertain? :) No need to yell; Mike will do his best. He's got many other tasks though... 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 From dabenavidesd at yahoo.es Mon Dec 7 17:03:45 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 7 Dec 2009 16:03:45 +0000 (GMT) Subject: [M3devel] Looking to update cm3 manual page. Message-ID: <611913.58311.qm@web23606.mail.ird.yahoo.com> Hi: probably you want to take look the DEBUG pragma of Cambridge Modula-3 cam3: http://web.archive.org/web/20040103230522/www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/m3.pdf or here http://web.archive.org/web/20040714091911/http://www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/index.html the pragmas explained there are actually documented to be in the sources of cm3 see history notes http://opencm3.net/about-cm3.html I think there is a table of compiler options for cam3 (page 54 and 55 which have some of it also listed in the cm3 -? message of the pdf document above) and of "pass 0" of it which are listed there on page 57. Page 56 have a list of pragmas ( http://web.archive.org/web/20050112061744/www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/node42.html#SECTION00630000000000000000 ) also see the traditional CM3 and DEC SRC pragma list (http://opencm3.net/doc/help/cm3/pragmas.html) but there isn't more information about <*INTRINSIC*> pragma than see http://opencm3.net/about-cm3.html I think there other DEC in-house pragmas which the cm3 sources inhereted and are not linked to the compiler process itself like PRAGMA SPEC <*SPEC ...*> (i.e. http://opencm3.net/doc/help/gen_html/libm3/src/sequence/Sequence.ig.html see doc in http://web.archive.org/web/19970605182158/www.research.digital.com/SRC/esc/Esc-speclang.html) and those of .lm3 Larch Modula-3 checking (they were in .lm3 files i.e m3-libs/m3core/src/text/Text.lm3 , I think compiler didn't handle it. but still there is a syntax grammar that can be used to build a syntax checker of it http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-72.html ). Another pragma that could be documented is the one present and explained in the documentation <*TRACE*>: http://apotheca.hpl.hp.com/ftp/pub/DEC/SRC/hypertext/Modula-3/user.html see source code in m3-sys/m3front/src/misc/Token.m3 and documentation in the SRC Modula-3 version 2.11 documentation: Hope this can be useful for the man page and improved documentation you can take in account --- El mi?, 2/12/09, Peter Eiserloh escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Looking to update cm3 manual page. > Para: "M3Devel" > Fecha: mi?rcoles, 2 de diciembre, 2009 12:01 > Hi all, > > It has been more than half a year since I last looked at > the > CM3 manual page. I am now looking at the it in > preparation > for the release of version 5.8, and noticing some > deficiencies. > > I asking for help in identifying any further places it is > lacking. > I can integrate any feedback into a revised manual page, > and > submit an updated version back to the archives. > > > Currently identified deficiencies: > > o The manual page should explicitly state which version of > the > compiler it documents. > > o The sub-section "Expected Directory Structure" needs a > better > discussion, especially an introduction. > > o The discussion of mode option "-ship" mentions > environment > variable CM3_INSTALL_ROOT, yet in cm3.cfg we set > INSTALL_ROOT > without the "CM3_" prefix. This should > be resolved. > > ** What is the exact meaning of these two? Is > one recognized > by the compiler, and the other by > the supporting quake > code? > > o The ENVIRONMENT section does not mention > CM3_INSTALL_ROOT > at all. Add a discussion about both > INSTALL_ROOT, and > CM3_INSTALL_ROOT. > > ** Am I missing any other environment variables? > > o Missing command line options for the compiler: > > - I currently have "-g", but no discussion of > -gstabs. > No discussion about not supporting DWARF (or > do we?). > > o Compiler unique language features, (i.e., pragmas). > The > reference books (Nelson, and Harbison) give a list > of > suggested pragmas. The manual page should list > the ones > supported by the CM3 compiler explicitly, and show > their > syntax. > > ** Can someone list for me the pragmas supported by > the > current (5.8.4) compiler. > > o Should list any limitations of either the compiler, or > the library suite provided with the compiler. > > > For example, the WIDECHAR is limited by its 16-bit > size > to only a portion of the unicode character set > (the basic multi lingual plane), whereas a unicode > character is 20-bits, and we would need either a > 24-bit or 32-bit sized type to contain it all. > > ** Are there any other known limitations of the > compiler, > or library suite? > - length of identifier? > - length of TEXT (ie, > memory) > - length of filenames, or > pathname > (some architectures > may have differences, > ie MS-Windows). > > o There should be a discussion of the @m3XXX runtime > library command line options. > > o There should be an EXAMPLE section, with example > source code (Hello world), along with supporting > m3makefile. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > > | > +--------------------------------------------------------+ > > > > From hosking at cs.purdue.edu Mon Dec 7 18:42:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Dec 2009 12:42:13 -0500 Subject: [M3devel] race condition setting act.handle? In-Reply-To: References: Message-ID: On 7 Dec 2009, at 01:55, Jay K wrote: > pthread_create(act.handle) followed at some point by use of act.handle in the new thread. > Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. Good question. Previously we had fork inside activeMu, which prevented the forked thread running until the parent release activeMu. Now we don't. Perhaps that was the problem. > > > What is to cause act.handle to be stored before the new thread starts and uses act.handle? > > > For this reason in Win32 I create the thread suspended, store the handle, resume the thread. > Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 9 14:15:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Dec 2009 13:15:47 +0000 Subject: [M3devel] full source paths in debug info? Message-ID: I'll check the archive..but..we should have full paths to source files in debug information. That is what you always get with C and C++ on Windows. I understand they aren't particularly useful when binaries are copied across machines. But they are very useful when they aren't. Real life scenario, the debugger shows me: 0012fc2c 0041fd50 stubgen!Formatter__PutText+0xc6 [..\src\formatter\Formatter.m3 @ 275] 0012fc98 00410192 stubgen!IntfStubCode__Header+0x90 [..\src\IntfStubCode.m3 @ 25] 0012fd78 00409444 stubgen!StubCode__GenStub+0x14b [..\src\StubCode.m3 @ 91] 0012fdc8 00409117 stubgen!AstToType__ProcessNetObj+0x1e7 [..\src\AstToType.m3 @123] 0012fe38 00422b2b stubgen!AstToType__OneStub+0x59e [..\src\AstToType.m3 @ 95] 0012fe88 00443305 stubgen!Main__DoRun+0x3db [..\src\Main.m3 @ 64] 0012febc 00422b99 stubgen!M3ToolFrame__Startup+0x87 [..\src\toolframe\M3ToolFrame.m3 @ 27] 0012fee0 0056c3f4 stubgen!Main_M3+0x35 [..\src\Main.m3 @ 76] 0012ff24 0056b9cc stubgen!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLinker.m3 @ 399] If we did things correctly, I'd just copy/paste these paths into the file.open dialog. Instead I get to be slower. Here is C++ for example: C:\dev2\cm3.2\m3-ui\zeus\NT386>type t.c int main() { __debugbreak(); } C:\dev2\cm3.2\m3-ui\zeus\NT386>cl -Zi t.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. C:\dev2\cm3.2\m3-ui\zeus\NT386>\bin\x86\cdb.exe -g t.exe t!main+0x3: 00401013 cc int 3 0:000> .lines Line number information will be loaded 0:000> u . t!main+0x3 [c:\dev2\cm3.2\m3-ui\zeus\nt386\t.c @ 3]: - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 9 15:16:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Dec 2009 14:16:51 +0000 Subject: [M3devel] deadlock in Win32 threads? Message-ID: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 9 17:13:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Dec 2009 11:13:03 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: Message-ID: <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 07:59:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 06:59:34 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 08:43:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 07:43:42 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, Message-ID: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 10 10:18:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Dec 2009 10:18:24 +0100 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> Quoting Jay K : > Hm. First, what changed is probably the movement of stuff from > traced to untraced?? > > Which makes it more efficient and more like pthreads. > > I might try putting that back. > > What I have now though, is that in T, Mutex, and Condition, I put an > integer field writeToBlahBlah. > > Every time before Lock(giant), whatever, t, m, c, I have I write to > that field. > > That drastically mitigates this problem and it goes away. I don't really feel confident with such solutions. Maybe I'm a bit old-fashioned, but I think that code like a threading subsystem should be completely understood and `correct' (according to all available means). In my experience it is almost impossible to _test_ the `correctness' of concurrent and concurrency implementations, as the next usage scenario or even a simple hardware upgrade will reveal one unsafe or unprotected critical region after the other. And reveal doesn't mean `point to' here, but just indicate that something must be wrong somewhere ;-) So to keep the good spirit of Modula-3, I'd really favour a simple and completely understandable implementation even if it has some performance drawbacks. Deadlock can be completely avoided if all critical resources are known and a well-defined locking order is heeded for each access. If there is only one code path that may use another order, this deadlock will occur earlier or later, preferably when there is also stress to get something else working for a milestone or a release. All this should not be misinterpreted to depreciate testing; but there can never be enough tests, and there is only a limited time to perform them regularly. Olaf > However that still leaves me with a similar deadlock. > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > This thread is stuck trying to get the heap lock. > > It is I presume "inCritical" already. > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > The first thread has the heap lock, and isn't giving it up: > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > > > Suspending the second thread does work, but it stays inCritical. > > I'm guessing at some of this. > > > > The giant lock is no longer relevant. > > > > > > I don't see why pthreads doesn't behave the same. > > > > I'll have to read the code more. > > > > Hm. inCritical maybe shouldn't be set actually? > > I'll dig more. > > > > > > - Jay > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > > > Jay, you're the one closest to the Win32 threading code these days. > Hope you can track it down. > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I > could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild > everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll > probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe > [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 > [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 > [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 > [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe > [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 > [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 > [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 > [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 > [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 > [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 > [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c > [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 > [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf > [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within > the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is > obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it > works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers > make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references > within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > -- 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 From jay.krell at cornell.edu Thu Dec 10 13:34:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 12:34:08 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> Message-ID: I understand, but I don't understand Birrel's algorithm, though I can see we did and do implement it exactly. He stated and implemented it at a time where touching pointers didn't call into the garbage collector. The idea that just touching a pointer call into all that code is a bit hard to reason about imho...since I don't really understand all that code.. Our use of the giant lock in LockMutex/UnlockMutex appears to be in the interest of implementing a simple optimization suggested by Birrel, but one we didn't have. Ultimately I believe we remove the giant lock and emulate Java's implementation, but I don't understant it either. I can implement faithfully but I'd like to understand it. Maybe I can/should do that earlier rather than later? That moves us from not-well-understood place to another, but where the one is clearly better. - Jay > Date: Thu, 10 Dec 2009 10:18:24 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Quoting Jay K : > > > Hm. First, what changed is probably the movement of stuff from > > traced to untraced?? > > > > Which makes it more efficient and more like pthreads. > > > > I might try putting that back. > > > > What I have now though, is that in T, Mutex, and Condition, I put an > > integer field writeToBlahBlah. > > > > Every time before Lock(giant), whatever, t, m, c, I have I write to > > that field. > > > > That drastically mitigates this problem and it goes away. > > I don't really feel confident with such solutions. Maybe I'm a bit > old-fashioned, but I think that code like a threading subsystem should > be completely understood and `correct' (according to all available means). > > In my experience it is almost impossible to _test_ the `correctness' of > concurrent and concurrency implementations, as the next usage scenario or > even a simple hardware upgrade will reveal one unsafe or unprotected > critical region after the other. And reveal doesn't mean `point to' here, > but just indicate that something must be wrong somewhere ;-) > > So to keep the good spirit of Modula-3, I'd really favour a simple and > completely understandable implementation even if it has some performance > drawbacks. > > Deadlock can be completely avoided if all critical resources are known > and a well-defined locking order is heeded for each access. If there is > only one code path that may use another order, this deadlock will occur > earlier or later, preferably when there is also stress to get something > else working for a milestone or a release. > > All this should not be misinterpreted to depreciate testing; but there > can never be enough tests, and there is only a limited time to perform > them regularly. > > Olaf > > > However that still leaves me with a similar deadlock. > > > > This thread is stuck trying to suspend everyone: > > > > 0:000> ~*k > > > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > > This thread is stuck trying to get the heap lock. > > > > It is I presume "inCritical" already. > > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > > ChildEBP RetAddr > > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > > > > > > The first thread has the heap lock, and isn't giving it up: > > > > > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > > 0:000> ?? m3core!ThreadWin32__heapLock > > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > > +0x00c OwningThread : 0x00001258 > > > > > > > > > > Suspending the second thread does work, but it stays inCritical. > > > > I'm guessing at some of this. > > > > > > > > The giant lock is no longer relevant. > > > > > > > > > > > > I don't see why pthreads doesn't behave the same. > > > > > > > > I'll have to read the code more. > > > > > > > > Hm. inCritical maybe shouldn't be set actually? > > > > I'll dig more. > > > > > > > > > > > > - Jay > > > > > > > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > > From: hosking at cs.purdue.edu > > Date: Wed, 9 Dec 2009 11:13:03 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > > > > > > > Jay, you're the one closest to the Win32 threading code these days. > > Hope you can track it down. > > > > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > > > Win32. > > > > I have a wierd system..but I think the bug is real. > > In particular I was testing a small threading change on head. > > How alertable is managed, to remove its write in LockMutex, so I > > could remove the giant lock there. > > But I just had the alertable changes. > > > > > > It was hanging starting Juno. > > So I tried to test release. > > You can't use head Juno with release m3core...and I didn't rebuild > > everything. I'll do that. > > So I patched up release m3core to be binary compatible. (I'll > > probably check that in.) > > > > > > Juno still hangs. > > > > > > Here is what I see: > > > > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > > ~ is thread; * is all; k is stack. > > > > [edited] > > > > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > > ChildEBP RetAddr > > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > [c:\dev2\cm3 > > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 > > [..\src\thread\WIN32\ThreadWin32.m3 > > @ 960] > > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 > > [..\src\runtime\common\R > > TCollector.m3 @ 2253] > > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 > > [..\src\thread\WIN32\Thread > > Win32.m3 @ 111] > > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > > ... > > > > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > > ChildEBP RetAddr > > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > [c:\dev2\cm > > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 > > [..\src\thread\WIN32\ThreadWin32 > > .m3 @ 276] > > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 > > [..\src\thread\WIN32\ThreadWin > > 32.m3 @ 995] > > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 > > [..\src\runtime\common\R > > TCollector.m3 @ 716] > > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 > > [..\src\runtime\common\RTC > > ollector.m3 @ 666] > > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 > > [..\src\runtime\common\R > > TCollector.m3 @ 671] > > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 > > [..\src\runtime\common\RT > > Allocator.m3 @ 364] > > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c > > [..\src\runtime\common\R > > TAllocator.m3 @ 222] > > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 > > [..\src\runtime\common\ > > RTAllocator.m3 @ 120] > > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf > > [..\src\JunoCompile.m3 > > @ 987] > > ... > > > > > > Let's look at two of our important locks: > > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > > > > 0:006> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 2 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000b0 > > +0x010 LockSemaphore : 0x00000708 > > +0x014 SpinCount : 0 > > > > > > 0:006> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000b34 > > +0x010 LockSemaphore : 0x000006ec > > +0x014 SpinCount : 0 > > > > > > So you can see there is a circularity and deadlock. > > Thread 6 owns giant lock and is waiting for heap lock. > > Thread 7 owns heap lock and is waiting for giant lock. > > > > > > This occurs because Win32 LockMutex uses traced references within > > the giant lock. ? > > Use of traced references implies a possible need to take the heap lock. > > Doing darn near anything implies a need to use the giant lock. > > > > > > Any ideas Tony? > > > > > > I'm not crazy or have a messed up tree, right? > > I mean, now that I've discussed it, the deadlock potential is > > obviously there, right? > > > > > > Pthreads is safe of course, no giant lock. > > > > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > > That should help? > > The giant lock would still remain though. > > > > > > Now, we know that condition variables are implementable well enough on Win32. > > Either with a giant lock, or how Java does it. > > Aside: I don't fully understand the Java implementation, but if it > > works, it is goodness. > > It has no giant lock. I don't understand how the sequence numbers > > make it work. > > > > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > > that it works at ll..doesn't interact well with traced references > > within its own implementation? > > Maybe this stuff can be teased apart? > > > > > > Same thing with a coherent (I think) release build: > > > > 0:008> ~*k > > > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > > > ... > > > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > > ChildEBP RetAddr > > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > > > > 0:008> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 5 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000d0 > > +0x010 LockSemaphore : 0x00000700 > > +0x014 SpinCount : 0 > > > > > > 0:008> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000080 > > +0x010 LockSemaphore : 0x000006fc > > +0x014 SpinCount : 0 > > > > > > 80 has the heap lock and is trying to get the giant lock > > D0 has the giant lock and is trying to get the heap lock > > Because of the use of traced references in LockMutex. > > > > > > - Jay > > > > > > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 10 17:10:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 11:10:58 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> The second thread should *not* be inCritical when trying to LockHeap. Are you sure that is the case? As it stands you need to be able to suspend a thread even if it is waiting on the heap lock (i.e., because the collector thread already holds the lock). On 10 Dec 2009, at 01:59, Jay K wrote: > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > From hosking at cs.purdue.edu Thu Dec 10 17:12:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 11:12:45 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, Message-ID: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 17:12:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 16:12:58 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> , <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> Message-ID: I was wrong on that point. Upon debugging it I found the stack pointer was deemed bad, because I had context* vs. context** wrong. That we even check the stack pointer is dubious but it is the historical behavior -- I merely made the code to do it far more direct/faster/reliable. - Jay > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:10:58 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > The second thread should *not* be inCritical when trying to LockHeap. Are you sure that is the case? As it stands you need to be able to suspend a thread even if it is waiting on the heap lock (i.e., because the collector thread already holds the lock). > > On 10 Dec 2009, at 01:59, Jay K wrote: > > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > > Which makes it more efficient and more like pthreads. > > I might try putting that back. > > > > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > > That drastically mitigates this problem and it goes away. > > > > > > However that still leaves me with a similar deadlock. > > > > > > This thread is stuck trying to suspend everyone: > > > > 0:000> ~*k > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > > > > This thread is stuck trying to get the heap lock. > > It is I presume "inCritical" already. > > > > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > > ChildEBP RetAddr > > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > > The first thread has the heap lock, and isn't giving it up: > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > > 0:000> ?? m3core!ThreadWin32__heapLock > > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > > +0x00c OwningThread : 0x00001258 > > > > > > Suspending the second thread does work, but it stays inCritical. > > I'm guessing at some of this. > > > > The giant lock is no longer relevant. > > > > > > I don't see why pthreads doesn't behave the same. > > > > I'll have to read the code more. > > > > Hm. inCritical maybe shouldn't be set actually? > > I'll dig more. > > > > > > - Jay > > > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > > From: hosking at cs.purdue.edu > > Date: Wed, 9 Dec 2009 11:13:03 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > > > Win32. > > > > I have a wierd system..but I think the bug is real. > > In particular I was testing a small threading change on head. > > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > > But I just had the alertable changes. > > > > > > It was hanging starting Juno. > > So I tried to test release. > > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > > > > Juno still hangs. > > > > > > Here is what I see: > > > > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > > ~ is thread; * is all; k is stack. > > > > [edited] > > > > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > > ChildEBP RetAddr > > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > > @ 960] > > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > > TCollector.m3 @ 2253] > > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > > Win32.m3 @ 111] > > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > > ... > > > > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > > ChildEBP RetAddr > > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > > .m3 @ 276] > > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > > 32.m3 @ 995] > > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > > TCollector.m3 @ 716] > > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > > ollector.m3 @ 666] > > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > > TCollector.m3 @ 671] > > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > > Allocator.m3 @ 364] > > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > > TAllocator.m3 @ 222] > > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > > RTAllocator.m3 @ 120] > > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > > @ 987] > > ... > > > > > > Let's look at two of our important locks: > > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > > > > 0:006> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 2 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000b0 > > +0x010 LockSemaphore : 0x00000708 > > +0x014 SpinCount : 0 > > > > > > 0:006> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000b34 > > +0x010 LockSemaphore : 0x000006ec > > +0x014 SpinCount : 0 > > > > > > So you can see there is a circularity and deadlock. > > Thread 6 owns giant lock and is waiting for heap lock. > > Thread 7 owns heap lock and is waiting for giant lock. > > > > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > > Use of traced references implies a possible need to take the heap lock. > > Doing darn near anything implies a need to use the giant lock. > > > > > > Any ideas Tony? > > > > > > I'm not crazy or have a messed up tree, right? > > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > > > > Pthreads is safe of course, no giant lock. > > > > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > > That should help? > > The giant lock would still remain though. > > > > > > Now, we know that condition variables are implementable well enough on Win32. > > Either with a giant lock, or how Java does it. > > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > > It has no giant lock. I don't understand how the sequence numbers make it work. > > > > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > > that it works at ll..doesn't interact well with traced references within its own implementation? > > Maybe this stuff can be teased apart? > > > > > > Same thing with a coherent (I think) release build: > > > > 0:008> ~*k > > > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > > > ... > > > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > > ChildEBP RetAddr > > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > > > > 0:008> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 5 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000d0 > > +0x010 LockSemaphore : 0x00000700 > > +0x014 SpinCount : 0 > > > > > > 0:008> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000080 > > +0x010 LockSemaphore : 0x000006fc > > +0x014 SpinCount : 0 > > > > > > 80 has the heap lock and is trying to get the giant lock > > D0 has the giant lock and is trying to get the heap lock > > Because of the use of traced references in LockMutex. > > > > > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 17:44:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 16:44:12 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: ok. LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. BroadcastHeap just sets a boolean that is looked at by UnlockHeap. Not my doing, but I just moved it from head to release. LockMutex I changed to just EnterCriticalSection. My doing. BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, then BroadcastHeap would have to call Broadcast and take the giant lock. I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. - Jay From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 10 18:32:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 12:32:36 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> I thought you were saying you had a problem with access to traced state... On 10 Dec 2009, at 11:44, Jay K wrote: > ok. > > LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. > BroadcastHeap just sets a boolean that is looked at by UnlockHeap. > Not my doing, but I just moved it from head to release. > LockMutex I changed to just EnterCriticalSection. > My doing. > > > BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. > That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, > then BroadcastHeap would have to call Broadcast and take the giant lock. > > > I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:12:45 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. > > On 10 Dec 2009, at 02:43, Jay K wrote: > > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 18:33:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 17:33:42 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> , <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> Message-ID: I did. I was. I think it is ok now. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 12:32:36 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I thought you were saying you had a problem with access to traced state... On 10 Dec 2009, at 11:44, Jay K wrote: ok. LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. BroadcastHeap just sets a boolean that is looked at by UnlockHeap. Not my doing, but I just moved it from head to release. LockMutex I changed to just EnterCriticalSection. My doing. BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, then BroadcastHeap would have to call Broadcast and take the giant lock. I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. - Jay From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:22:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:22:48 +0000 Subject: [M3devel] "port simple race condition fix from head related to stopping a thread before/after it has any traced references" In-Reply-To: <20091211111426.0EA142474001@birch.elegosoft.com> References: <20091211111426.0EA142474001@birch.elegosoft.com> Message-ID: Something is fishy here. The change is fine, but there could only be a problem if suspending the thread didn't work? You know, the stack value shouldn't be changing? I'm pretty sure I saw this be a problem on some configuration, but maybe it was only user threads and maybe they are relevantly different? Also Tony is it ok to RTHeapRep.FlushThreadState unconditionally here? - Jay > Date: Fri, 11 Dec 2009 12:14:26 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 12:14:26 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > release_branch_cm3_5_8 > ThreadPThreadC.c > > Log message: > port simple race condition fix from head related to stopping a thread before/after it has any traced references > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:35:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:35:02 +0000 Subject: [M3devel] slight differences in m3core release vs. head? Message-ID: Tony, which versions do you prefer in which branch? C:\dev2\cm3.release_branch_cm3_5_8\m3-libs\m3core\src\runtime\common>diff -u C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3 RTHeapStats.m3 --- C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3 2009-12- 10 09:04:05.546875000 -0800 +++ RTHeapStats.m3 2009-12-11 02:51:53.468750000 -0800 @@ -330,7 +330,7 @@ VAR fp: UNTRACED REF ADDRESS := start; BEGIN (* scan the stack or registers *) - WHILE fp < stop DO + WHILE fp <= stop DO WITH page = RTHeapRep.AddressToPage(fp^), d = page.desc DO IF page # NIL AND d.space = RTHeapRep.Space.Current THEN VisitPage(page); C:\dev2\cm3.release_branch_cm3_5_8\m3-libs\m3core\src\runtime\common>diff -u C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3 RTCollector.m3 --- C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3 2009-12- 11 02:50:02.234375000 -0800 +++ RTCollector.m3 2009-12-11 02:51:44.781250000 -0800 @@ -519,7 +519,9 @@ PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN - IF NOT (start < stop) THEN RETURN END; + IF start = NIL AND stop = NIL THEN + RETURN; + END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO @@ -2210,7 +2212,7 @@ END; END WeakCleaner; There are also a bunch of user thread diffs I haven't looked at closely. And a bunch of diffs I understand. I think off by one thing in NoteStackLocations is subtle. The ranges come from code that might not be so precise or might be themselves off by one. I believe in Win32 I pass in for stop the "just past the end" value. In which case you want "<". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:44:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:44:27 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: Btw, I don't understand how all the barriers work so seemingly lock free. Or maybe they do often take locks? That is why I don't trust arbitrary invocations of barriers, since I don't know how long the results stay valid. I really just need to read and internalize this barrier stuff. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 13:08:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 12:08:27 +0000 Subject: [M3devel] "start, limit" vs. "start, stop" In-Reply-To: <20091211120558.37E0F2474001@birch.elegosoft.com> References: <20091211120558.37E0F2474001@birch.elegosoft.com> Message-ID: > note that there are still "start, stop" pairs, in addition to the > "start, limit" pairs There are still some "start, stop", but they are consistent, things compile. C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3(519):PROCEDURE NoteStackLocations (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(297):PROCEDURE GetThread (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(329):PROCEDURE ScanPages (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(353):PROCEDURE ScanThreadRoots (start, stop: ADDRESS; on_stack: BOOLEAN) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(383):PROCEDURE ScanThreadPageRoots (start, stop: ADDRESS; on_stack: BOOLEAN) = C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3(976):PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) = C:\dev2\cm3.2\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3(808):PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) = I think the names are in the type, like for calling with named parameters, but the functions don't actually have to match. The perfectionist in me says they should all be consistent though. The pragmatist says basically no change is worthwhile here, even the ones already made. - Jay > Date: Fri, 11 Dec 2009 13:05:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 13:05:58 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: Tag: > release_branch_cm3_5_8 > RTThread.i3 > cm3/m3-libs/m3core/src/thread/POSIX/: Tag: > release_branch_cm3_5_8 > ThreadPosix.i3 > ThreadPosix.m3 > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > release_branch_cm3_5_8 > ThreadPThread.m3 > cm3/m3-libs/m3core/src/thread/WIN32/: Tag: > release_branch_cm3_5_8 > ThreadWin32.m3 > > Log message: > port from head: rename parameter in function pointer type from "stop" > to "limit" > note that there are still "start, stop" pairs, in addition to the > "start, limit" pairs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 14:55:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 08:55:26 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: Soon we will make the barriers lock free. Right now they lock the heap (blurgh). But we will still need them to be inCritical to prevent GC occurring in the middle of a barrier. On 11 Dec 2009, at 06:44, Jay K wrote: > Btw, I don't understand how all the barriers work so seemingly lock free. > Or maybe they do often take locks? > That is why I don't trust arbitrary invocations of barriers, since I don't know how long > the results stay valid. I really just need to read and internalize this barrier stuff. > > > - Jay > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:12:45 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. > > On 10 Dec 2009, at 02:43, Jay K wrote: > > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:05:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Message-ID: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:09:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:09:37 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:17:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:17:16 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:41:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:41:53 +0000 Subject: [M3devel] FW: some open bugs In-Reply-To: <4B1C34ED.1E75.00D7.1@scires.com> References: , , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com>, , <4B1C34ED.1E75.00D7.1@scires.com> Message-ID: Sorry no not at this time. I haven't looked in a bit and it stumped me at the time. I think we should either have a build per C runtime version or /maybe/ link to libmt.lib. - Jay >> Can you be more specific about the nature of the "windows C runtime version issue" you report below ? Regards, Randy >>> Jay K 12/6/2009 4:00 AM >>> > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 15:57:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 09:57:13 -0500 Subject: [M3devel] "port simple race condition fix from head related to stopping a thread before/after it has any traced references" In-Reply-To: References: <20091211111426.0EA142474001@birch.elegosoft.com> Message-ID: <45DB4B67-5013-4A8D-BDEB-8EFE9B08C1F2@cs.purdue.edu> On 11 Dec 2009, at 06:22, Jay K wrote: > Something is fishy here. The change is fine, but there could only be a problem > if suspending the thread didn't work? You know, the stack value shouldn't > be changing? I'm pretty sure I saw this be a problem on some configuration, > but maybe it was only user threads and maybe they are relevantly different? > > Also Tony is it ok to RTHeapRep.FlushThreadState unconditionally here? I think so: only stopped threads have this done to them. If they are using the thread state (for allocation) then they are inCritical. > > - Jay > > > Date: Fri, 11 Dec 2009 12:14:26 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/11 12:14:26 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > > release_branch_cm3_5_8 > > ThreadPThreadC.c > > > > Log message: > > port simple race condition fix from head related to stopping a thread before/after it has any traced references > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:02:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:02:16 +0000 Subject: [M3devel] Why do we not check stackbase=NIL anymore in ProcessOther? In-Reply-To: <20091211145750.8D48E2474001@birch.elegosoft.com> References: <20091211145750.8D48E2474001@birch.elegosoft.com> Message-ID: I know what I was thinking, but it doesn't make sense any more. I could have sworn I saw a race where the value changed between the check and the subsequent read/use. That makes sense, in that I don't change the value under a lock. But it doesn't make sense, in that the changer should be suspended. The check is done shortly after in the C code though. There is just one read, and the purported race is gone. It should be ok. The one uncertainty on my part is what the HeapRep.FlushState does. I looked at, but I didn't follow through as to the other uses of the state it changes. - Jay > Date: Fri, 11 Dec 2009 15:57:50 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 09/12/11 15:57:50 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Tidy a little. > Why do we not check stackbase=NIL anymore in ProcessOther? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 16:06:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 10:06:03 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: > Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? > > > I'm not sure this is going to work out, but: > I'm "rewriting" stuff to use a separate event for alerting. > alertable goes away > There will be two events: > waitEvent, for condition variables > alertEvent, for alerting > > > roughly speaking: > > > AlertPause: WaitForSingleObject(alertEvent) > AlertWait: > alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) > Alert(t): SetEvent(t.alertEvent); > TestAlert: alerted := WaitForSingleObject(alertEvent, 0); > > > It seems simple enough. > That shows all the ingredients. > That'll eliminate a lot of the global locking. > And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. > You can't just use the Java code because it doesn't include alertability. > You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. > The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:07:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:07:23 +0000 Subject: [M3devel] RTOS.Crash In-Reply-To: <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> References: <20091211114257.4EA062474001@birch.elegosoft.com>, <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> Message-ID: > We should do the same for POSIX too I think. Posix just calls abort. Posix: PROCEDURE Crash () = BEGIN Cstdlib.abort (); LOOP END; (* wait *) END Crash; Win32: PROCEDURE Crash () = CONST Magic = 1 * ADRSIZE (INTEGER); (* == offset of "fp" in this frame *) VAR fp: ADDRESS := ADR (fp) + Magic; (* == my frame pointer *) BEGIN IF WinBase.IsDebuggerPresent () # 0 THEN (* I moved these three lines up. *) WinBase.DebugBreak (); END; RTThread.SuspendOthers (); RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); RTSignal.RestoreHandlers (); (* so we really do crash... *) Exit (-1); END Crash; That said..I'm missing something and I should review the code. Obviously there are calls elsewhere to DumpStack, and they or may not be similarly crufty. /Actually/ one thing I'd like is for the m3core to be able to dump better callstacks. Like, the ability to carry more debuginfo of its own custom format in itself. Like, to get line numbers. - Jay From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:00:35 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 We should do the same for POSIX too I think. On 11 Dec 2009, at 12:42, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/12/11 12:42:57 Modified files: cm3/m3-libs/m3core/src/runtime/WIN32/: Tag: release_branch_cm3_5_8 RTOS.m3 Log message: port from head: very small change that makes debugging sometimes much better (break right into debugger, don't waste time trying to suspend threads and dump stacks, the debugger does a much better job of suspending threads and usually (if you have symbols) of dumping stacks) If you aren't using a debugger, then no change. The thing about RestoreHandlers can probably just be removed since in my brief experience the DebugBreak works fine before it. Really it can probably just go like this: If debugger debugbreak ELSE suspend others, maybe dumpstack one of the important parts restore handlers probably can be removed Exit(-1) also important though maybe should be TerminateProcess which is much quicker/cleaner doesn't run all the dllmains though currently I just made the small change of moving the debugbreak much earlier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:09:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:09:20 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> References: , <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Message-ID: No. I answered my question -- it is in case of really long pauses -- over 4billion milliseconds. The waits are broken up into chunks of that size. We use a 53bit? mantissa longreal to represent seconds whereas Win32 wait is 32bit number of milliseconds. The one doesn't fit in the other. - Jay Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:06:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 16:10:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 10:10:10 -0500 Subject: [M3devel] RTOS.Crash In-Reply-To: References: <20091211114257.4EA062474001@birch.elegosoft.com>, <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> Message-ID: <09E070FF-B13F-405F-A6E9-6F73AEEFE680@cs.purdue.edu> OK, cool. On 11 Dec 2009, at 10:07, Jay K wrote: > > We should do the same for POSIX too I think. > > Posix just calls abort. > > Posix: > PROCEDURE Crash () = > BEGIN > Cstdlib.abort (); > LOOP END; (* wait *) > END Crash; > > > Win32: > > > PROCEDURE Crash () = > CONST Magic = 1 * ADRSIZE (INTEGER); (* == offset of "fp" in this frame *) > VAR fp: ADDRESS := ADR (fp) + Magic; (* == my frame pointer *) > BEGIN > IF WinBase.IsDebuggerPresent () # 0 THEN (* I moved these three lines up. *) > WinBase.DebugBreak (); > END; > RTThread.SuspendOthers (); > RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); > RTSignal.RestoreHandlers (); (* so we really do crash... *) > Exit (-1); > END Crash; > > > That said..I'm missing something and I should review the code. > Obviously there are calls elsewhere to DumpStack, and they or may not be similarly crufty. > > > /Actually/ one thing I'd like is for the m3core to be able to dump better callstacks. > Like, the ability to carry more debuginfo of its own custom format in itself. > Like, to get line numbers. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 11 Dec 2009 10:00:35 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > We should do the same for POSIX too I think. > > On 11 Dec 2009, at 12:42, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 12:42:57 > > Modified files: > cm3/m3-libs/m3core/src/runtime/WIN32/: Tag: > release_branch_cm3_5_8 > RTOS.m3 > > Log message: > port from head: very small change that makes debugging sometimes much better > (break right into debugger, don't waste time trying to suspend threads > and dump stacks, the debugger does a much better job of suspending > threads and usually (if you have symbols) of dumping stacks) > If you aren't using a debugger, then no change. > > The thing about RestoreHandlers can probably just be removed since > in my brief experience the DebugBreak works fine before it. > > Really it can probably just go like this: > If debugger > debugbreak > ELSE > suspend others, maybe > dumpstack one of the important parts > restore handlers probably can be removed > Exit(-1) also important though maybe should be TerminateProcess which is much quicker/cleaner > doesn't run all the dllmains > > though currently I just made the small change of moving the debugbreak much earlier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:09:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:09:44 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> References: , <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Message-ID: ps: not to mention the exponent! From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 AlertPause polls instead of one big wait? Date: Fri, 11 Dec 2009 15:09:20 +0000 No. I answered my question -- it is in case of really long pauses -- over 4billion milliseconds. The waits are broken up into chunks of that size. We use a 53bit? mantissa longreal to represent seconds whereas Win32 wait is 32bit number of milliseconds. The one doesn't fit in the other. - Jay Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:06:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 19:12:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 13:12:00 -0500 Subject: [M3devel] Why do we not check stackbase=NIL anymore in ProcessOther? In-Reply-To: References: <20091211145750.8D48E2474001@birch.elegosoft.com> Message-ID: <1884D92B-9409-4AD5-966B-D3E566B7784E@cs.purdue.edu> On 11 Dec 2009, at 10:02, Jay K wrote: > I know what I was thinking, but it doesn't make sense any more. > I could have sworn I saw a race where the value changed between > the check and the subsequent read/use. > That makes sense, in that I don't change the value under a lock. > But it doesn't make sense, in that the changer should be suspended. > The check is done shortly after in the C code though. > There is just one read, and the purported race is gone. > It should be ok. The one uncertainty on my part is what the HeapRep.FlushState does. > I looked at, but I didn't follow through as to the other uses of the state it changes. Ah, yes, I see the test now in the C code. Doesn't make any sense that doing it there should make any difference though. As for the flushing of the heap state, all that is doing is relinquishing the thread's heap allocation context so that GC can occur. > > > - Jay > > > > Date: Fri, 11 Dec 2009 15:57:50 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/12/11 15:57:50 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > > > Log message: > > Tidy a little. > > Why do we not check stackbase=NIL anymore in ProcessOther? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sat Dec 12 05:50:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 11 Dec 2009 23:50:57 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: <4B22D975.1E75.00D7.1@scires.com> Jay, I notice you say something about Win9x below. I never had much success with Win9x back in the cm3 v4.1 days. Farshad and company stated that they would only support WindowsNT4.0 back then. I think it would be fine at this point to just support the newer stuff (Windows NT4.0 / 2000 / XP / Vista / Windows 7) and not worry about the old 9x versions or even NT3.5. I've been watching all the activity on threading and mutexes. I keep updating from the HEAD branch and rebuilding on XP and Vista to make sure stuff still compiles. I must admit all these low-level changes concern me for the same reasons Olaf outlined a few days ago. I've not had much time to devote to cm3 lately, but I will try to test using some of my multi-threaded programs as soon as I can. However, I fear it will be hard to tell if something is only "slightly broken" or "slightly misbehaves" because unless you see a crash or obvious behavior flaw, you won't know it is "slightly" broken. I did contribute a "Mutex Checker" test program a few weeks back. I'll keep running it, but it doesn't test all the alert and condition variable stuff. I think we need some test programs that can prove correctness, but these are going to be hard to develop I fear. Regards, Randy >>> Jay K 12/11/2009 9:17 AM >>> [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 06:37:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 05:37:44 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <4B22D975.1E75.00D7.1@scires.com> References: , , <4B22D975.1E75.00D7.1@scires.com> Message-ID: Randy, I was just going to ask about this..: building with Visual C++ 2.0 (banner says copyright 1994): Time.mo : error LNK2001: unresolved external symbol "_GetSystemTimeAsFileTime at 4" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_GetIcon at 12" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_LoadImageA at 28" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_Remove at 8" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_ReplaceIcon at 12" ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange" ThreadWin32.mo : error LNK2001: unresolved external symbol "_InterlockedCompareExchange at 12" RTOS.mo : error LNK2001: unresolved external symbol "_IsDebuggerPresent at 0" m3core.dll : error LNK1120: 8 unresolved externals building with Visual C++ 4.0 (circa 1996?): ThreadWin32.mo : error LNK2001: unresolved external symbol _InterlockedCompareExchange at 12 ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange m3core.dll : fatal error LNK1120: 2 unresolved externals building with Visual C++ 4.2 (circa 1996?): works Which is also some significant measure of what operating systems work. I had deleted \cm3\lib. If you build in m3-win\import-libs, then the problems drop to just InterlockedCompareExchange, and that is easily fixed. Though again it is a measure of what operating system versions will work. I'm really undecided here. Our dependency on anything beyond Windows 95/NT 3.1, maybe even Win32s, is really slight or nonexistant. If you look at the above list for example, InterlockedCompareExchange I /just/ introduced to replace a lock, a lock that I had only introduced recently as part of removing the giant lock (the lock is much smaller). IsDebuggerPresent is really optional. GetSystemTimeAsFileTime is trivial to do without. ImageList stuff probably isn't needed -- we certainly get stuff at the wrong layer because of a certain part of our architecture. You know, normally in C / C++, there's no comctl32.dll support at any lower level, whoever needs it just #includes commctl.h. It is our "wrappers" that introduce this dependency. The way I discover the stack boundaries might not work on Win9x/Win32s, but it might. For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007. If all that works, things are better than they were for a long time. For many months Juno would sometimes hang due to a bug that affected all programs. Granted, we didn't necessarily ever release that bug. In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD. For better and for worse, these parts of the system do need work imho. My changes are also mostly for the simpler. Of course nobody can decide what is "simple". The change to remove the giant lock from LockMutex/UnlockMutex agrees with Birrel's paper, which only implies the lock might be there for an optimization elsewhere, an optimization that we didn't have. Let me know of any slight or suspected problem and esp. let me run the code. We should be ok, or better. :) For the alert thing we could do a version check and/or GetProcAddress on QueueUserAPC, or actually I suspect it is easy to be Win9x compatible. You'd have each thread open/create its own anonymous pipe and to alert the thread you'd just write a byte the pipe. I could test older systems in VMs. I mostly just use XP. - Jay Date: Fri, 11 Dec 2009 23:50:57 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? Jay, I notice you say something about Win9x below. I never had much success with Win9x back in the cm3 v4.1 days. Farshad and company stated that they would only support WindowsNT4.0 back then. I think it would be fine at this point to just support the newer stuff (Windows NT4.0 / 2000 / XP / Vista / Windows 7) and not worry about the old 9x versions or even NT3.5. I've been watching all the activity on threading and mutexes. I keep updating from the HEAD branch and rebuilding on XP and Vista to make sure stuff still compiles. I must admit all these low-level changes concern me for the same reasons Olaf outlined a few days ago. I've not had much time to devote to cm3 lately, but I will try to test using some of my multi-threaded programs as soon as I can. However, I fear it will be hard to tell if something is only "slightly broken" or "slightly misbehaves" because unless you see a crash or obvious behavior flaw, you won't know it is "slightly" broken. I did contribute a "Mutex Checker" test program a few weeks back. I'll keep running it, but it doesn't test all the alert and condition variable stuff. I think we need some test programs that can prove correctness, but these are going to be hard to develop I fear. Regards, Randy >>> Jay K 12/11/2009 9:17 AM >>> [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 12 06:59:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Dec 2009 00:59:03 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: , , <4B22D975.1E75.00D7.1@scires.com> Message-ID: FreeBSD pthreads has not previously been supported. Just Linux, Solaris, OSX. On 12 Dec 2009, at 00:37, Jay K wrote: > > Randy, I was just going to ask about this..: > > > > > > building with Visual C++ 2.0 (banner says copyright 1994): > > Time.mo : error LNK2001: unresolved external symbol "_GetSystemTimeAsFileTime at 4" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_GetIcon at 12" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_LoadImageA at 28" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_Remove at 8" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_ReplaceIcon at 12" > ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange" > ThreadWin32.mo : error LNK2001: unresolved external symbol "_InterlockedCompareExchange at 12" > RTOS.mo : error LNK2001: unresolved external symbol "_IsDebuggerPresent at 0" > m3core.dll : error LNK1120: 8 unresolved externals > > > > building with Visual C++ 4.0 (circa 1996?): > ThreadWin32.mo : error LNK2001: unresolved external symbol _InterlockedCompareExchange at 12 > ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange > m3core.dll : fatal error LNK1120: 2 unresolved externals > > > > building with Visual C++ 4.2 (circa 1996?): > works > > > > Which is also some significant measure of what operating systems work. > > I had deleted \cm3\lib. If you build in m3-win\import-libs, then the problems drop to just InterlockedCompareExchange, and that is easily fixed. Though again it is a measure of what operating system versions will work. > > > > > > I'm really undecided here. Our dependency on anything beyond Windows 95/NT 3.1, maybe even Win32s, is really slight or nonexistant. If you look at the above list for example, InterlockedCompareExchange I /just/ introduced to replace a lock, a lock that I had only introduced recently as part of removing the giant lock (the lock is much smaller). IsDebuggerPresent is really optional. GetSystemTimeAsFileTime is trivial to do without. ImageList stuff probably isn't needed -- we certainly get stuff at the wrong layer because of a certain part of our architecture. You know, normally in C / C++, there's no comctl32.dll support at any lower level, whoever needs it just #includes commctl.h. It is our "wrappers" that introduce this dependency. > > The way I discover the stack boundaries might not work on Win9x/Win32s, but it might. > > > > > > For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007. > > If all that works, things are better than they were for a long time. > > For many months Juno would sometimes hang due to a bug that affected all programs. > > Granted, we didn't necessarily ever release that bug. > > In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD. > > For better and for worse, these parts of the system do need work imho. > > > > > > My changes are also mostly for the simpler. Of course nobody can decide what is "simple". > > The change to remove the giant lock from LockMutex/UnlockMutex agrees with Birrel's paper, which only implies the lock might be there for an optimization elsewhere, an optimization that we didn't have. > > Let me know of any slight or suspected problem and esp. let me run the code -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 07:47:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 06:47:28 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? Message-ID: cloning headers vs. indirection/win32 So..I've been a champion of pushing code into C to avoid cloning headers. I'm not sure the following statement is logical: It is easier to clone "windows.h" than "libc.h". The possible logic is that there is less variation. There is very little #ifdef in windows.h, whereas "libc.h" contains both #ifdefs and there are to some extent n different versions. Another possible explanation is that windows.h was cloned long ago not by me and "libc.h" I've had to deal with more, on "new" systems. It is an exaggeration to say OpenBSD/NetBSD/FreeBSD/Linux/Solaris/Darwin etc. are "completely" different independent rewrites but it is also an exaggeration to say they are "the same". It is tempting to say the stat struct is the only problem, but it isn't. If it IS logical, then some of this could/should be undone for Windows. In particular I'm pretty sympathetic to having the Modula-3 code use Initialize/Enter/LeaveCriticalSection directly. With the following caveats: - maybe it isn't logical - as things are currently, there is more opportunity to merge pthreads and Win32 implementation Going "back" to a somewhat more optimized Win32 implementation is a bit of a barrier to merging them. I'll probably things asis in this regard. You know..to be "consistent", I should go through ThreadWin32.m3's: FROM WinNT IMPORT LONG, HANDLE, DWORD, UINT32; FROM WinBase IMPORT WaitForSingleObject, INFINITE, CloseHandle, CreateThread, ResumeThread, Sleep, SuspendThread, GetThreadContext, SetLastError, GetLastError, CREATE_SUSPENDED, GetCurrentThreadId, InterlockedCompareExchange, InterlockedExchange, InterlockedIncrement, InterlockedDecrement, SetEvent, WAIT_OBJECT_0, CreateEvent, WaitForMultipleObjects; FROM ThreadContext IMPORT PCONTEXT; and reduce those and/or wrap them in C like is done for m3core/unix. Well, maybe. Constants are easy, plus statically link a la hand.obj/Uconstants.obj. Functions are easy. "base" types like LONG, HANDLE, DWORD, UINT32 we just go ahead and clone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 08:27:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 07:27:33 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? In-Reply-To: References: Message-ID: Actually it appears the indirection is needed for CRITICAL_SECTION. WinNT.i3: (* NOTE: "PRTL_CRITICAL_SECTION" is declared as a Modula-3 opaque type and then immediately revealed so that "EnterCriticalSection()" and "LeaveCriticalSection()" won't require checks by the GC wrapper routines. Clearly, if a Windows critical section is inside an M3 traced ref (which moves!) the system is going to crash. Hence, the extra GC check isn't needed. *) TYPE PRTL_CRITICAL_SECTION <: ADDRESS; REVEAL PRTL_CRITICAL_SECTION = UNTRACED BRANDED "WinNT.PRTL_CRITICAL_SECTION" REF RTL_CRITICAL_SECTION; But we could still have the global locks (slotLock, activeLock, initLock, perfLock etc.) be "direct" CRITICAL_SECTIONS and just the "dynamic" ones (Thread.Mutex) have the indirection. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sat, 12 Dec 2009 06:47:28 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? cloning headers vs. indirection/win32 So..I've been a champion of pushing code into C to avoid cloning headers. I'm not sure the following statement is logical: It is easier to clone "windows.h" than "libc.h". The possible logic is that there is less variation. There is very little #ifdef in windows.h, whereas "libc.h" contains both #ifdefs and there are to some extent n different versions. Another possible explanation is that windows.h was cloned long ago not by me and "libc.h" I've had to deal with more, on "new" systems. It is an exaggeration to say OpenBSD/NetBSD/FreeBSD/Linux/Solaris/Darwin etc. are "completely" different independent rewrites but it is also an exaggeration to say they are "the same". It is tempting to say the stat struct is the only problem, but it isn't. If it IS logical, then some of this could/should be undone for Windows. In particular I'm pretty sympathetic to having the Modula-3 code use Initialize/Enter/LeaveCriticalSection directly. With the following caveats: - maybe it isn't logical - as things are currently, there is more opportunity to merge pthreads and Win32 implementation Going "back" to a somewhat more optimized Win32 implementation is a bit of a barrier to merging them. I'll probably things asis in this regard. You know..to be "consistent", I should go through ThreadWin32.m3's: FROM WinNT IMPORT LONG, HANDLE, DWORD, UINT32; FROM WinBase IMPORT WaitForSingleObject, INFINITE, CloseHandle, CreateThread, ResumeThread, Sleep, SuspendThread, GetThreadContext, SetLastError, GetLastError, CREATE_SUSPENDED, GetCurrentThreadId, InterlockedCompareExchange, InterlockedExchange, InterlockedIncrement, InterlockedDecrement, SetEvent, WAIT_OBJECT_0, CreateEvent, WaitForMultipleObjects; FROM ThreadContext IMPORT PCONTEXT; and reduce those and/or wrap them in C like is done for m3core/unix. Well, maybe. Constants are easy, plus statically link a la hand.obj/Uconstants.obj. Functions are easy. "base" types like LONG, HANDLE, DWORD, UINT32 we just go ahead and clone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 16:25:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 15:25:44 +0000 Subject: [M3devel] to share code between Join and AlertJoin or not? Message-ID: Here's a case where it is not clear if the code is worth sharing: Join and AlertJoin share XJoin: PROCEDURE XJoin (t: T; alertable: BOOLEAN): REFANY RAISES {Alerted} = VAR (* The order of the handles is important. *) handles := ARRAY [0..1] OF HANDLE {t.act.handle, NIL(*alertEvent*)}; wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; IF alertable THEN handles[1] := GetActivation().alertEvent; END; wait := WaitForMultipleObjects(1 + ORD(alertable), ADR(handles[0]), 0, INFINITE); <* ASSERT wait # WAIT_TIMEOUT *> <* ASSERT wait = WAIT_OBJECT_0 OR wait = (WAIT_OBJECT_0 + 1) *> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT wait = WAIT_OBJECT_0 + 1 *> <* ASSERT alertable *> RAISE Alerted; END; END XJoin; PROCEDURE Join(t: T): REFANY = <*FATAL Alerted*> BEGIN IF DEBUG THEN ThreadDebug.Join(t); END; RETURN XJoin(t, alertable := FALSE); END Join; PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} = BEGIN IF DEBUG THEN ThreadDebug.AlertJoin(t); END; RETURN XJoin(t, alertable := TRUE); END AlertJoin; OR without code sharing, it'd go like: PROCEDURE Join(t: T): REFANY = VAR wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForSingleObject(t.act.handle, INFINITE); <* ASSERT wait = WAIT_OBJECT_0 *> t.joined := 1; RETURN t.result; END Join; PROCEDURE AlertJoin (t: T): REFANY RAISES {Alerted} = VAR (* The order of the handles is important. *) handles := ARRAY [0..1] OF HANDLE {t.act.handle, GetActivation().alertEvent}; wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForMultipleObjects(2, ADR(handles[0]), 0, INFINITE); <* ASSERT wait # WAIT_TIMEOUT *> <* ASSERT wait = WAIT_OBJECT_0 OR wait = (WAIT_OBJECT_0 + 1) *> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT wait = WAIT_OBJECT_0 + 1 *> RAISE Alerted; END; END AlertJoin; anyone have strong feelings either way? If we used win32 alertable waits, then the case for code sharing would be stronger, it'd go like: PROCEDURE XJoin (t: T; alertable: BOOLEAN): REFANY RAISES {Alerted} = VAR wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForSingleObjectEx(t.act.handle, INFINITE, ORD(alertable)); <* ASSERT wait = WAIT_OBJECT_0 OR wait = WAIT_IO_COMPLETION*> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT alertable *> RAISE Alerted; END; END XJoin; - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 01:37:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 00:37:43 +0000 Subject: [M3devel] AlertPause(0) is alertable? Message-ID: If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 04:41:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091213033734.E108E2474002@birch.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> Message-ID: 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 04:46:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 03:46:57 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 05:56:08 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 12 Dec 2009 23:56:08 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: Message-ID: <4B242C23.1E75.00D7.1@scires.com> My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 05:56:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 04:56:18 +0000 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: <4B242C23.1E75.00D7.1@scires.com> References: , <4B242C23.1E75.00D7.1@scires.com> Message-ID: Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:02:34 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:02:34 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com> Message-ID: <4B242DA5.1E75.00D7.1@scires.com> Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:04:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:04:43 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242DA5.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com> Message-ID: Randy, ok, thanks it sounds like you did one of the two things. 1) Remerge old diffs to new tree. but not 2) Lift out what is common into a common file, instead of forking the entire file. I didn't mean to imply Unix gui should look like Windows gui. Just that the large amounts of common code should not be duplicated. Probably what'd work is have one merged file with some if's sprinkled. I think what Unix gui should look like is a perpetually unsolved problem and the answer is somewhere between "terrible" and "like Windows", with KDE at least near the second extreme. :) Trestle seems to be among the uglier Unix gui libraries actually.. It'd be nice if there was an option to adapt to the current "theme", but Trestle to me is a very large unknown.. - Jay Date: Sun, 13 Dec 2009 00:02:34 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:12:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:12:21 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: <4B242FF0.1E75.00D7.1@scires.com> Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:16:31 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:16:31 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: , <4B242C23.1E75.00D7.1@scires.com> Message-ID: <4B2430EA.1E75.00D7.1@scires.com> Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. Regards, Randy >>> Jay K 12/12/2009 11:56 PM >>> Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:13:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:13:09 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:15:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:15:49 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: [pesky truncation again!] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] FW: Win32/ScrollerVBTClass.m3 Date: Sun, 13 Dec 2009 05:13:09 +0000 Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:22:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:22:25 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com> Message-ID: <4B24324C.1E75.00D7.1@scires.com> Jay: You are correct that I did not attempt to factor out common code. At the time, we were more interested in correct behavior, and such factoring did not provide any benefits to the executing code. The benefit of such factoring is in reducing the source tree size and potentially improved maintainability, if done right. So to that end, I applaud your efforts. Regards, Randy >>> Jay K 12/13/2009 12:04 AM >>> Randy, ok, thanks it sounds like you did one of the two things. 1) Remerge old diffs to new tree. but not 2) Lift out what is common into a common file, instead of forking the entire file. I didn't mean to imply Unix gui should look like Windows gui. Just that the large amounts of common code should not be duplicated. Probably what'd work is have one merged file with some if's sprinkled. I think what Unix gui should look like is a perpetually unsolved problem and the answer is somewhere between "terrible" and "like Windows", with KDE at least near the second extreme. :) Trestle seems to be among the uglier Unix gui libraries actually.. It'd be nice if there was an option to adapt to the current "theme", but Trestle to me is a very large unknown.. - Jay Date: Sun, 13 Dec 2009 00:02:34 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:37:55 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:37:55 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <4B2435EE.1E75.00D7.1@scires.com> Jay: My recollection is that I had multiple source trees to work with, including the then current repository, my original 4.1 source tree, and the modified 4.1 source tree we got from Farshad. There may have been others; I don't remember; its been a while. I also vaguely recall doing some comparisons against the DEC SRC sources, which I also had. I never used mentor, so I can't comment there. As far as whether Modula-3 is still ahead of its time, I think the work we are all doing is necessary if the language is to survive. Right now, I think we are playing catch up in terms of having viable implementations on a sufficient base of modern OS and processors. I still prefer Modula-3 as a language and I think it has a lot to offer. >From an educational standpoint, I can't think of a better language for one to learn good programming principles and practices. Perhaps if more computer science students started out with Modula-3 the world would be a better place... Back when Microsoft first came out with .NET, I seriously considered working on a Modula-3 implementation for .NET and talked with some folks at Microsoft about it, but my career and family kept me busy and I never got very far. Regards, Randy >>> Jay K 12/13/2009 12:13 AM >>> Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:34:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:34:21 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? Message-ID: https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:38:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:38:46 +0000 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: <4B2430EA.1E75.00D7.1@scires.com> References: , , <4B242C23.1E75.00D7.1@scires.com>, , <4B2430EA.1E75.00D7.1@scires.com> Message-ID: The 4.1 code has the bug (this is probably identical but I haven't done a mechanical diff, but it is plain to see it has the bug): (I bought 4.1 too). PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1000.0D0)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; - Jay Date: Sun, 13 Dec 2009 00:16:31 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. Regards, Randy >>> Jay K 12/12/2009 11:56 PM >>> Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:42:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:42:19 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: Message-ID: I seem to have quite a knack for placing periods in column 76 by accident. This was truncated right at the end. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 13 Dec 2009 05:34:21 +0000 > Subject: [M3devel] pickle bug..solved?.. not supposed to work? > > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:52:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:52:53 -0500 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: Message-ID: <4B243970.1E75.00D7.1@scires.com> Jay: I've done a lot with Pickles and with NetObj. I switched to the v2 version a long time ago and never looked back. IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. Regards, Randy >>> Jay K 12/13/2009 12:34 AM >>> https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:47:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:47:29 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: I keep trying to understand Trestle but I keep failing. I tried to read the comments explaining how its locking works and I got lost quickly. I suspect that compares well to other GUI libraries in that they probably just don't do threading well. Easy to understand though. The Trestle apps are all pretty ugly and oddly behaved. Granted, I have no "real use" for them. I just exercise them a bit as test cases. I did notice you made the scrollbars look "nice" on Windows. The close box is marked "C". The grow box is marked "G". Yuck. As I said though, the more I look into Trestle, the more I think it is implementing a rather complete "windows system" and not just a library of widgets, nor even widgets + resizing algorithms. Nor even just widgets + resizing + event routing. Like, it seems to also manage clipping, knowing what needs redrawing, etc. But I'm not sure. It adds up to a lot of code, is my concern. That is good and bad. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:50:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:50:59 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <4B243970.1E75.00D7.1@scires.com> References: , <4B243970.1E75.00D7.1@scires.com> Message-ID: I assume there is a need to keep the code around for compatibility? You know -- to read existing files? And to keep testing that? And write them at least so the tests can read them back? But maybe we should take a read-only attitude? And switch the quake netobj=netobj1 to netobj=netobj2? It's tough..if you convert-upon-write, and people are running old programs, you'll break their files. It's also tough, you know, I think this stuff is too automatic. I'm pretty sure we should change the Text internal representation, but I'm also pretty sure the persistance (disk) representation is automatically derived from the transient (memory) representation and changing the second breaks the first. You know, I suspect it is like those systems that do: struct foo a; fwrite(&a, sizeof(a)); but just with endian/wordsize conversions and hashes/typeid to do checks upon read, so it won't crash if you change things, but it also won't read back successfully. Maybe the v1 limitations are good as well, in that maybe it is faster, and sometimes the limitations don't matter??? - Jay Date: Sun, 13 Dec 2009 00:52:53 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? Jay: I've done a lot with Pickles and with NetObj. I switched to the v2 version a long time ago and never looked back. IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. Regards, Randy >>> Jay K 12/13/2009 12:34 AM >>> https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:10:40 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:10:40 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: , , <4B242C23.1E75.00D7.1@scires.com>, , <4B2430EA.1E75.00D7.1@scires.com> Message-ID: <751737BC-0080-4F0C-975E-11C17246937F@cs.purdue.edu> Given that I based pthreads on win32 its no surprise that I replicated the bug. I've fixed it in ThreadPThread on the trunk. Probably needs copying over to the release branch. On 13 Dec 2009, at 00:38, Jay K wrote: > The 4.1 code has the bug (this is probably identical but I haven't done a mechanical diff, > but it is plain to see it has the bug): > (I bought 4.1 too). > > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = > VAR amount, thisTime: LONGREAL; > CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; > VAR self: T; > BEGIN > self := Self(); > amount := n; > WHILE amount > 0.0D0 DO > thisTime := MIN (Limit, amount); > amount := amount - thisTime; > WinBase.EnterCriticalSection(cm); > InnerTestAlert(self); > self.alertable := TRUE; > <* ASSERT(self.waitingOn = NIL) *> > WinBase.LeaveCriticalSection(cm); > EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1000.0D0)); > WinBase.EnterCriticalSection(cm); > self.alertable := FALSE; > IF self.alerted THEN > (* Sadly, the alert might have happened after we timed out on the > semaphore and before we entered "cm". In that case, we need to > decrement the semaphore's count *) > EVAL WinBase.WaitForSingleObject(self.waitSema, 0); > InnerTestAlert(self); > END; > WinBase.LeaveCriticalSection(cm); > END; > END AlertPause; > > - Jay > > > > Date: Sun, 13 Dec 2009 00:16:31 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] AlertPause(0) is alertable? > > Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. > Regards, > Randy > > >>> Jay K 12/12/2009 11:56 PM >>> > Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. > > > Note that the 3.6 code doesn't seem to get it right: > > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = > VAR amount, thisTime: LONGREAL; > CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; > VAR self: T; > BEGIN > self := Self(); > amount := n; > WHILE amount > 0.0D0 DO > thisTime := MIN (Limit, amount); > amount := amount - thisTime; > WinBase.EnterCriticalSection(cm); > InnerTestAlert(self); > self.alertable := TRUE; > <* ASSERT(self.waitingOn = NIL) *> > WinBase.LeaveCriticalSection(cm); > EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); > WinBase.EnterCriticalSection(cm); > self.alertable := FALSE; > IF self.alerted THEN > (* Sadly, the alert might have happened after we timed out on the > semaphore and before we entered "cm". In that case, we need to > decrement the semaphore's count *) > EVAL WinBase.WaitForSingleObject(self.waitSema, 0); > InnerTestAlert(self); > END; > WinBase.LeaveCriticalSection(cm); > END; > END AlertPause; > > The 3.6 and current user threads code seems ok, but I've not very familiar with it. > > This might be one of those things though that's been consistently broken for so long that it's best not to depend on? > Prefer AlertPause(0.01) over AlertPause(0)?? > > > - Jay > > > > Date: Sat, 12 Dec 2009 23:56:08 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] AlertPause(0) is alertable? > > My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. > > Regards, > Randy > > >>> Jay K 12/12/2009 7:37 PM >>> > If I call AlertPause with <= 0 time, should I recieve alerts? > Current pthread/win32 implementations: no. > They say if time <= then return end before doing much. > My suspicion: yes. > > > Thread.i3: > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; > (* Like "Pause", but if the thread is marked alerted at the time of > the call or sometime during the wait, raise "Alerted". *) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:11:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:11:44 -0500 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: , <4B243970.1E75.00D7.1@scires.com> Message-ID: <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> Yes, v1 is there in case anyone has v1 pickles they want to decode. On 13 Dec 2009, at 00:50, Jay K wrote: > I assume there is a need to keep the code around for compatibility? > You know -- to read existing files? > And to keep testing that? > And write them at least so the tests can read them back? > > > But maybe we should take a read-only attitude? > > > And switch the quake netobj=netobj1 to netobj=netobj2? > > > It's tough..if you convert-upon-write, and people are > running old programs, you'll break their files. > > > It's also tough, you know, I think this stuff is too automatic. > I'm pretty sure we should change the Text internal representation, > but I'm also pretty sure the persistance (disk) representation > is automatically derived from the transient (memory) > representation and changing the second breaks the first. > > > You know, I suspect it is like those systems > that do: > > > struct foo a; > fwrite(&a, sizeof(a)); > > > but just with endian/wordsize conversions and > hashes/typeid to do checks upon read, so it > won't crash if you change things, but it also won't > read back successfully. > > > Maybe the v1 limitations are good as well, in that maybe > it is faster, and sometimes the limitations don't matter??? > > > - Jay > > > Date: Sun, 13 Dec 2009 00:52:53 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? > > Jay: > > I've done a lot with Pickles and with NetObj. > > I switched to the v2 version a long time ago and never looked back. > > IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. > > Regards, > Randy > > >>> Jay K 12/13/2009 12:34 AM >>> > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Dec 13 19:09:57 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 13 Dec 2009 12:09:57 -0600 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <4B243970.1E75.00D7.1@scires.com> References: <4B243970.1E75.00D7.1@scires.com> Message-ID: <4B252DF5.7020400@lcwb.coop> Randy Coleburn wrote: > Jay: > > I've done a lot with Pickles and with NetObj. > > I switched to the v2 version a long time ago and never looked back. > > IMO, we should switch over to v2 exclusively and consider v1 > obsolete. Perhaps some others should comment on this to see if they > share my opinion. I am using pickles and have done work inside pickle code. I agree strongly on this. V2 pickle code can read pickle files written by V1 pickle code (or at least V2 pickles have code that appears to do so), so old pickle files can still be read. This adaptation is made at dynamically at read time by looking at the pickle file header, so no user action is required. So there is really no benefit to using V1 pickle code. There is one thing that has been a problem for me in the past. In PM3, importing "Pickle" gets you version 2, while in CM3, "Pickle" gets you V1 and you have to import "Pickle2" to get V2. This means code that is to compile/run in either PM3 or CM3 has to have changes to actual source code. I have scripted this, but it is a messy and fragile kludge. I will probably drop maintaining PM3/CM3 compilability in the future. Anybody else doing this? There is one other messy problem that comes to mind. Both versions have a few hard-coded signatures for a few language-predefined types that do not consistently follow the byte order used in type signatures in general. They differ both between the versions and from the general rule. In some case(s), the byte ordering used is downright bizarre. I don't remember for certain, but I think I fixed V2 to adapt to V1's conventions on this when reading V1 pickle files. > > Regards, > Randy > > >>> Jay K 12/13/2009 12:34 AM >>> > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with > pickles From hosking at cs.purdue.edu Sun Dec 13 19:28:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:28:23 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: <75934296-836C-4024-B61B-1321002FB567@cs.purdue.edu> Trestle is of historic interest to the M3 community. We should try to keep it living and breathing. On 12 Dec 2009, at 22:46, Jay K wrote: > eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. > scrollertvbtclass is pretty close, though current adds "shadows". > Maybe we're ok in practise, but I still don't like it. > > (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging > feeling that Trestle reinvents far more than most other gui libraries.) > > - Jay > > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Sun, 13 Dec 2009 03:41:25 +0000 > Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 > > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:30:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:30:18 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242DA5.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> Message-ID: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > Jay: > > Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. > > Regards, > Randy > > >>> Jay K 12/12/2009 10:41 PM >>> > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 02:43:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 01:43:56 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: Randy's changes make the Windows GUI look more like Windows. My changes make mentor not crash starting up just by checking for NIL and taking a lock. I don't understand Trestle's locking and the comments explaining it were too long for me to understand, so I'm just guessing. Given how ugly and non-uniform X Windows GUIs tend to be, Trestle being a good example -- it has its own unique ugly look, changing is not a bad idea, but not done here. - Jay From: hosking at cs.purdue.edu Date: Sun, 13 Dec 2009 13:30:18 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 14 12:42:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Dec 2009 12:42:57 +0100 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> References: , <4B243970.1E75.00D7.1@scires.com> <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> Message-ID: <20091214124257.35dc33zjnkws0ks0@mail.elegosoft.com> Quoting Tony Hosking : > Yes, v1 is there in case anyone has v1 pickles they want to decode. I'd also vote for making V2 pickles the default. We could rename Pickle to Pickle1 and Pickle2 to Pickle and document this as an semantically incompatible change. Or is there really much interest in reading old pickle versions? Olaf > On 13 Dec 2009, at 00:50, Jay K wrote: > >> I assume there is a need to keep the code around for compatibility? >> You know -- to read existing files? >> And to keep testing that? >> And write them at least so the tests can read them back? >> >> >> But maybe we should take a read-only attitude? >> >> >> And switch the quake netobj=netobj1 to netobj=netobj2? >> >> >> It's tough..if you convert-upon-write, and people are >> running old programs, you'll break their files. >> >> >> It's also tough, you know, I think this stuff is too automatic. >> I'm pretty sure we should change the Text internal representation, >> but I'm also pretty sure the persistance (disk) representation >> is automatically derived from the transient (memory) >> representation and changing the second breaks the first. >> >> >> You know, I suspect it is like those systems >> that do: >> >> >> struct foo a; >> fwrite(&a, sizeof(a)); >> >> >> but just with endian/wordsize conversions and >> hashes/typeid to do checks upon read, so it >> won't crash if you change things, but it also won't >> read back successfully. >> >> >> Maybe the v1 limitations are good as well, in that maybe >> it is faster, and sometimes the limitations don't matter??? >> >> >> - Jay >> >> >> Date: Sun, 13 Dec 2009 00:52:53 -0500 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? >> >> Jay: >> >> I've done a lot with Pickles and with NetObj. >> >> I switched to the v2 version a long time ago and never looked back. >> >> IMO, we should switch over to v2 exclusively and consider v1 >> obsolete. Perhaps some others should comment on this to see if >> they share my opinion. >> >> Regards, >> Randy >> >> >>> Jay K 12/13/2009 12:34 AM >>> >> >> https://projects.elego.de/cm3/ticket/1068 >> >> >> >> >> >> I've only spent a few minutes here. >> >> Trying to find the relative code and such. >> >> >> >> >> >> The code is here: >> >> >> >> >> >> C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src >> >> >> >> I found it by looking near the top of the stack in >> >> the bug report -- NetObjTest.m3 -- and >> >> then dir /s/b NetObjTest.m3. >> >> >> >> or find . | grep NetObjTest.m3$ on Unix. >> >> >> >> >> >> It appears that Pickle v1 and v2 are both >> >> available in the same library. >> >> There is INTERFACE Pickle and INTERFACE Pickle2. >> >> >> >> >> >> It appears netobj can use either. >> >> >> >> If you look at the stack in the bug, there is a lot of "v1" stuff. >> >> >> >> >> >> We provide Quake functions: >> >> >> >> readonly proc netobjv1(intf, type) is >> ... >> >> end >> >> >> >> readonly proc Netobjv1(intf, type) is >> ... >> >> end >> >> >> >> readonly proc netobjv2(intf, type) is >> ... >> >> end >> >> >> >> readonly proc netobj(intf, type) is >> netobjv1(intf, type) >> end >> >> >> >> >> >> >> v1 pickles cannot cross endian/wordsize boundaries. >> >> >> >> >> >> I think the bug is not so much in the pickle code, nor in the netobj code, >> >> but in the test code, or the running of it. >> >> >> >> Tests involving v1 won't work crossing endian/wordsize boundaries. >> >> V1 tests probably should still run, and maybe detect the mismatch >> >> and just claim success? >> >> >> >> And then v2 should get better coverage? >> >> >> >> >> >> Any more bugs then? >> >> I was procrastinating on this because I've never done anything with pickles > > -- 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 From wagner at elegosoft.com Mon Dec 14 12:59:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Dec 2009 12:59:50 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> Quoting Jay K : > I keep trying to understand Trestle but I keep failing. > I tried to read the comments explaining how its locking > works and I got lost quickly. Actually the Trestle locking was `verified' after the implementation was finished with the Extended Statical Checker written at that time in Modula-3, too (but reimplemented since then in Java). See SRC report 159, for example here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 This is where all the locking level pragmas come from. > I suspect that compares well to other GUI libraries > in that they probably just don't do threading well. I always thought that using threads extensively to keep the application responding to user request was one of the strong areas of Testle. > Easy to understand though. > > The Trestle apps are all pretty ugly and oddly behaved. > Granted, I have no "real use" for them. I just exercise > them a bit as test cases. > > I did notice you made the scrollbars look "nice" on Windows. > > The close box is marked "C". > The grow box is marked "G". I grant that making it look better would probably increase the user acceptance. IMO there's no reason not to do that; but there hasn't been anybody interested in working on it yet. > Yuck. > > As I said though, the more I look into Trestle, the more I think > it is implementing a rather complete "windows system" and not > just a library of widgets, nor even widgets + resizing algorithms. > Nor even just widgets + resizing + event routing. > > Like, it seems to also manage clipping, knowing what needs > redrawing, etc. > > But I'm not sure. > > It adds up to a lot of code, is my concern. > > That is good and bad. Yes. But it's a huge project to integrate another GUI library into M3 and make it as useful as Trestle. 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 From jay.krell at cornell.edu Mon Dec 14 13:52:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 12:52:12 +0000 Subject: [M3devel] darwin user threads? Message-ID: It looks like make/get/set/swapcontext aren't viable on MacOSX 10.5. Better on 10.6? x86 getcontext seems to corrupt things such that a crash follows shortly. AMD64 just doesn't work. I happen to be experimenting again with see http://www.engelschall.com/pw/usenix/2000/pmt-html/ again to ease OpenBSD porting..and had some luck on Darwin, though had trouble getting the timer to trigger ever or more than once. $ cat 1.c && gcc -m32 1.c && file a.out && ./a.out ; gcc -m64 1.c && file a.out && ./a.out #include #include #include int main() { ucontext_t a; int b = getcontext(&a); printf("%d %d\n", b, errno); return 0; } a.out: Mach-O executable i386 0 0 Segmentation fault a.out: Mach-O 64-bit executable x86_64 -1 45 $ grep 45 /usr/include/sys/errno.h #define ENOTSUP 45 /* Operation not supported */ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 13:58:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 12:58:02 +0000 Subject: [M3devel] darwin user threads? In-Reply-To: References: Message-ID: oh, search the web for "Darwin getcontext": http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 14 Dec 2009 12:52:12 +0000 Subject: [M3devel] darwin user threads? It looks like make/get/set/swapcontext aren't viable on MacOSX 10.5. Better on 10.6? x86 getcontext seems to corrupt things such that a crash follows shortly. AMD64 just doesn't work. I happen to be experimenting again with see http://www.engelschall.com/pw/usenix/2000/pmt-html/ again to ease OpenBSD porting..and had some luck on Darwin, though had trouble getting the timer to trigger ever or more than once. $ cat 1.c && gcc -m32 1.c && file a.out && ./a.out ; gcc -m64 1.c && file a.out && ./a.out #include #include #include int main() { ucontext_t a; int b = getcontext(&a); printf("%d %d\n", b, errno); return 0; } a.out: Mach-O executable i386 0 0 Segmentation fault a.out: Mach-O 64-bit executable x86_64 -1 45 $ grep 45 /usr/include/sys/errno.h #define ENOTSUP 45 /* Operation not supported */ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 16:10:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 10:10:37 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> Do you mean mentor crashing on Windows? I would not like us to introduce new bugs to X11-based Trestle by merging Windows with X11 Trestle. On 13 Dec 2009, at 20:43, Jay K wrote: > Randy's changes make the Windows GUI look more like > Windows. My changes make mentor not crash starting > up just by checking for NIL and taking a lock. > I don't understand Trestle's locking and the comments > explaining it were too long for me to understand, > so I'm just guessing. > > Given how ugly and non-uniform X Windows GUIs tend to be, > Trestle being a good example -- it has its own > unique ugly look, changing is not a bad idea, > but not done here. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Sun, 13 Dec 2009 13:30:18 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 > > Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. > > > On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > > Jay: > > Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. > > Regards, > Randy > > >>> Jay K 12/12/2009 10:41 PM >>> > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 16:14:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 10:14:33 -0500 Subject: [M3devel] darwin user threads? In-Reply-To: References: Message-ID: <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> I knew about this issue at the time I implemented user threads and extensively tested it successfully on my OS X 10.5 laptop. It must have gotten broken when you reorganized everything. Can you put the _XOPEN_SOURCE define back in please! On 14 Dec 2009, at 07:58, Jay K wrote: > > oh, search the web for "Darwin getcontext": > > http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html > > Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 16:14:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 15:14:40 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242DA5.1E75.00D7.1@scires.com>, , <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, , <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> Message-ID: Yes it was crashing on Windows. It wasn't really "Windows-specific", it was specifically in the code Randy added. The two files are largely the same and they are both portable. It's just a matter of what pictures get drawn using the same underlying Trestle graphics functions. That is, the code is portable either way, it's just a behaviorial/visual decision that is made. You know, you could perfectly well allow: mentor -gui-style=windows mentor -gui-style=trestle You know, this isn't low level code, it is "middle". - Jay From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:10:37 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Do you mean mentor crashing on Windows? I would not like us to introduce new bugs to X11-based Trestle by merging Windows with X11 Trestle. On 13 Dec 2009, at 20:43, Jay K wrote:Randy's changes make the Windows GUI look more like Windows. My changes make mentor not crash starting up just by checking for NIL and taking a lock. I don't understand Trestle's locking and the comments explaining it were too long for me to understand, so I'm just guessing. Given how ugly and non-uniform X Windows GUIs tend to be, Trestle being a good example -- it has its own unique ugly look, changing is not a bad idea, but not done here. - Jay From: hosking at cs.purdue.edu Date: Sun, 13 Dec 2009 13:30:18 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote:Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards,Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 16:17:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 15:17:20 +0000 Subject: [M3devel] darwin user threads? In-Reply-To: <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> References: , <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> Message-ID: I didn't break it. It is not broken. I was "unhappy" at the non portability I had setup for OpenBSD..was trying sigaltstack again..was testing on Mac.. - Jay Subject: Re: [M3devel] darwin user threads? From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:14:33 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I knew about this issue at the time I implemented user threads and extensively tested it successfully on my OS X 10.5 laptop. It must have gotten broken when you reorganized everything. Can you put the _XOPEN_SOURCE define back in please! On 14 Dec 2009, at 07:58, Jay K wrote: oh, search the web for "Darwin getcontext": http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Dec 14 17:31:01 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 14 Dec 2009 08:31:01 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20091214134015.9044F2474001@birch.elegosoft.com>, , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu> Message-ID: <20091214163101.109F61A2078@async.async.caltech.edu> Alpha is little-endian because it's DEC and all DEC systems are little-endian. It's one of those religious wars, now long forgotten... DEC did win that war, after all, but much good it did them. Also regarding Trestle: there are several tech reports about it that explain the locking schemes in detail. Are there really other windowing systems out there that have similarly good support for multithreaded programs? (I've certainly never seen one...I think Trestle is very very cool.) Mika Jay K writes: >--_53b61834-1f8f-4857-9285-039cb0730d0c_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I assumed Alpha was little endian because it ran NT. >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > Linux and AIX?) > >Target.m3: > > (* big endian *) > > IF TextUtils.StartsWith(system=2C "PA") > > (* MIPS is definitely ambiguous! *) > OR TextUtils.StartsWith(system=2C "MIPS") > =20 > (* PPC is a little ambiguous? *) > OR TextUtils.StartsWith(system=2C "PPC") > > OR TextUtils.StartsWith(system=2C "SPARC") > OR TextUtils.StartsWith(system=2C "SOL") THEN > Little_endian :=3D FALSE=3B > END=3B > >Anyway it shouldn't be hard to track down. >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= >ng around...) > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= >s correct=2C and it /has/ no survived a fair number of combinations. I do c= >ross builds /almost/ without considering host and target. Er=2C except you = >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= >as started hitting me more often... it's just something where the compiler = >gets confused and does host math with target limitations=2C where it should= > do target math. > > - Jay > >From: hosking at cs.purdue.edu >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 >To: jay.krell at cornell.edu >CC: m3commit at elegosoft.com >Subject: Re: [M3commit] CVS Update: cm3 > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > code. I rewrote it=2C at least once. >Cross compiling works. >Native does not. >It must be the threshold variables in RTCollector. > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > earliest use of FP in the run-time linker. If they are broken you find ou= >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = >one point just fine on native Alpha 64-bit=2C so should not be too hard to = >fix. >I really thought I understood that code. > > - Jay > > >From: hosking at cs.purdue.edu >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 >To: jkrell at elego.de >CC: m3commit at elegosoft.com >Subject: Re: [M3commit] CVS Update: cm3 > >This suggests an m3cg backend compiler problem for floating point on SPARC6= >4. >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs >Changes by: jkrell at birch. 09/12/14 14:40:15 > >Modified files: > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > cm3/m3-libs/m3core/src/unix/: m3makefile=20 >Removed files: > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > >Log message: > updates so SPARC64_SOLARIS bootstrap can build > (possible tangent related to getting SPARC64_OPENBSD > to work -- problem apparently with the floating point > constants in RTCollector=2C such that Behind() is > always TRUE=2C even for the first allocation=2C so > access violate trying to garbage collect too > early=2C when self is still NULL) > > > = > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= >w=2C a lot of chips go either way these days (PowerPC little endian for NT = >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?)>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = >has been sitting around...)

The code I put in parse.c is definitely = >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = >fair number of combinations. I do cross builds /almost/ without considering= > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= >obably fix that pretty soon as it has started hitting me more often... it's= > just something where the compiler gets confused and does host math with ta= >rget limitations=2C where it should do target math.

 =3B- Jay>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> >
parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= >transform: none=3B white-space: normal=3B word-spacing: 0px=3B">=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= >te-space: normal=3B word-spacing: 0px=3B">
rd=3B">te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B">"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= >e-space: normal=3B word-spacing: 0px=3B">" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= >d-spacing: 0px=3B">apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= >ne=3B white-space: normal=3B word-spacing: 0px=3B">style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > 0px=3B">rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= >=2C at 10:43=2C Jay K wrote:
>

interchange-newline">
=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= >mpiling works.
Native does not.
It must be the threshold variables in= > RTCollector.

Yeah=2C I've= > been bitten by just that scenario in the past -- those are the earliest us= >e of FP in the run-time linker.  =3BIf they are broken you find out qui= >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > hard to fix.

e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= >ally thought I understood that code.

 =3B- Jay


=3D"ecxstopSpelling">From: =3B= >hosking at cs.purdue.edur>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To:verted-space"> =3Bjkrell at eleg= >o.de
CC: =3Bref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= >: Re: [M3commit] CVS Update: cm3

le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= >=3B word-spacing: 0px=3B">order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= >px=3B">
tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= >al=3B word-spacing: 0px=3B">"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > 0px=3B">eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= >ng: 0px=3B">: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">
Apple-style-span" style=3D"font-size: medium=3B">-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= >ackend compiler problem for floating point on SPARC64.
<= >/span>
= >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= >e:

CVSR= >OOT: pan>/usr/cvs
Changes by:ite-space: pre=3B"> jkrell at birch." style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= >iles:
> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 class=3D"ecxApple-converted-space"> =3B
xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= >rc/unix/: m3makefile =3B>
Removed files:
space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= >ignal.m3 =3B

Log= > message:
=3B"> updates so SPARC64_SOLARIS bootstrap can build
=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= >angent related to getting SPARC64_OPENBSD
-span" style=3D"white-space: pre=3B"> to work -- problem apparently = >with the floating point
ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= >s
span>always TRUE=2C even for the first allocation=2C so
cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= >rying to garbage collect too
=3D"white-space: pre=3B"> early=2C when self is still NULL)
>


ine">

>= > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- From jay.krell at cornell.edu Mon Dec 14 17:31:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:31:29 +0000 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). It still seemed to hang. (I realize you might not have meant that.) So what happens if none of our user threads have any work? Is that possible? Sure, I can make it so. Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). Will they actually wake up after that time? And we won't spin the CPU in the meantime? I guess I should test it out.. I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. But I wonder also..you have OpenBSD/x86 or sparc64? cd to that test bed, make, ./tcontext. It always seemed kind of jerky. I bet it'll seem "faster" with "real" timer. - Jay From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:39:31 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Main thread should call Yield if you want that behavior, not sleep. On 14 Dec 2009, at 14:57, Jay Krell wrote:CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/12/14 14:57:30 Added files: cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: Makefile config.c context.c context.h m3makefile tcontext.c Log message: working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ - This should be moved to m3core/src/thread/POSIX - Notice how I switched from virtual timer to real timer, in the test case that mimics m3core/src/thread/POSIX. "This seems to work much better." In particular, if the main thread does while (1) sleep(0) to let things run, nothing runs. The virtual time doesn't run down at all. If I make it a busy wait "while (1) ;" then it does work. Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). This solution might be preferred? Though it is slower to create a thread here, due to extra gymnastics to establish the initial context. Also still some experiments to try. _setjmp vs. setjmp vs. sigsetjmp. Best is probably sigsetjmp(1). using the same signal in both parts -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 17:39:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:39:40 +0000 Subject: [M3devel] Trestle In-Reply-To: <20091214163101.109F61A2078@async.async.caltech.edu> References: <20091214134015.9044F2474001@birch.elegosoft.com>, , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu> , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: I'm pretty sure Win32 doesn't have great GUI threading. Each Window has affinity to the thread it is created on -- all events to it are delivered to that thread. I'm pretty sure Java doesn't have great GUI threading. I remember historically that the X client (Xlib) wasn't historically even thread safe. However the server must be, since it is interacting with multiple processes. I doubt Trestle an really overcome the limits of the underlying systems though. My wording was poor. I can't remove Trestle, of course. But providing an alternative is still not a terrible idea. All my "research" (highly non scientific) says Qt is the way. As to how/if it would fit into Modula-3, I have little idea..and not a lot of time/interest either. The results generally look and behave better imho. The platform support (esp. Windows) is better. I'm aware that there are /many/ options and I'm aware of the unclear licensing issues. Probably it is one of those things that is free for use by "open source", and we probably quality, but not free for commercial use. Really, though, nothing going on here. Not worth arguing about. (Maybe I'll "merge" the X/Win32 Scroller, so that it is one body of code with ifs, but I'd leave X looking as it does (ugly), just reducing overall code volume and probably increasing maintainability (they don't directly correspond, but often largely do). - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 14 Dec 2009 08:31:01 -0800 > From: mika at async.async.caltech.edu > > > Alpha is little-endian because it's DEC and all DEC systems are > little-endian. It's one of those religious wars, now long forgotten... > DEC did win that war, after all, but much good it did them. > > Also regarding Trestle: there are several tech reports about it that > explain the locking schemes in detail. Are there really other windowing > systems out there that have similarly good support for multithreaded > programs? (I've certainly never seen one...I think Trestle is very > very cool.) > > Mika > > Jay K writes: > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I assumed Alpha was little endian because it ran NT. > >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= > >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > > Linux and AIX?) > > > >Target.m3: > > > > (* big endian *) > > > > IF TextUtils.StartsWith(system=2C "PA") > > > > (* MIPS is definitely ambiguous! *) > > OR TextUtils.StartsWith(system=2C "MIPS") > > =20 > > (* PPC is a little ambiguous? *) > > OR TextUtils.StartsWith(system=2C "PPC") > > > > OR TextUtils.StartsWith(system=2C "SPARC") > > OR TextUtils.StartsWith(system=2C "SOL") THEN > > Little_endian :=3D FALSE=3B > > END=3B > > > >Anyway it shouldn't be hard to track down. > >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= > >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= > >ng around...) > > > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= > >s correct=2C and it /has/ no survived a fair number of combinations. I do c= > >ross builds /almost/ without considering host and target. Er=2C except you = > >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= > >as started hitting me more often... it's just something where the compiler = > >gets confused and does host math with target limitations=2C where it should= > > do target math. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 > >To: jay.krell at cornell.edu > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > > code. I rewrote it=2C at least once. > >Cross compiling works. > >Native does not. > >It must be the threshold variables in RTCollector. > > > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > > earliest use of FP in the run-time linker. If they are broken you find ou= > >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = > >one point just fine on native Alpha 64-bit=2C so should not be too hard to = > >fix. > >I really thought I understood that code. > > > > - Jay > > > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 > >To: jkrell at elego.de > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > >This suggests an m3cg backend compiler problem for floating point on SPARC6= > >4. > >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/12/14 14:40:15 > > > >Modified files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > > cm3/m3-libs/m3core/src/unix/: m3makefile=20 > >Removed files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > > > >Log message: > > updates so SPARC64_SOLARIS bootstrap can build > > (possible tangent related to getting SPARC64_OPENBSD > > to work -- problem apparently with the floating point > > constants in RTCollector=2C such that Behind() is > > always TRUE=2C even for the first allocation=2C so > > access violate trying to garbage collect too > > early=2C when self is still NULL) > > > > > > = > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= > >w=2C a lot of chips go either way these days (PowerPC little endian for NT = > >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?) >>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= > >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= > >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = > >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = > >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= > >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= > >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= > >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= > >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= > >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= > >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= > >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = > >has been sitting around...)

The code I put in parse.c is definitely = > >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = > >fair number of combinations. I do cross builds /almost/ without considering= > > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= > >obably fix that pretty soon as it has started hitting me more often... it's= > > just something where the compiler gets confused and does host math with ta= > >rget limitations=2C where it should do target math.

 =3B- Jay >>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= > >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> > > >
>parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= > >transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= > >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= > >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= > >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= > >te-space: normal=3B word-spacing: 0px=3B">
>rd=3B"> >te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= > >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= > >=2C at 10:43=2C Jay K wrote:
 >>

>interchange-newline">
>=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= > >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = > >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= > >mpiling works.
Native does not.
It must be the threshold variables in= > > RTCollector.

Yeah=2C I've= > > been bitten by just that scenario in the past -- those are the earliest us= > >e of FP in the run-time linker.  =3BIf they are broken you find out qui= > >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= > >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > > hard to fix.

>e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= > >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = > >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= > >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= > >ally thought I understood that code.

 =3B- Jay


>=3D"ecxstopSpelling">From: =3B= > >hosking at cs.purdue.edu >r>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To: >verted-space"> =3Bjkrell at eleg= > >o.de
CC: =3B >ref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= > >: Re: [M3commit] CVS Update: cm3

>le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= > >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= > >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= > >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= > >=3B word-spacing: 0px=3B"> >order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= > >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= > >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= > >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= > >px=3B">
>tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= > >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= > >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= > >al=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = > >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= > >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= > >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= > >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B"> >-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= > >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= > >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= > >ng: 0px=3B"> >: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= > >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= > >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= > >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= > >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= > >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= > >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B">
>Apple-style-span" style=3D"font-size: medium=3B"> >-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= > >ackend compiler problem for floating point on SPARC64.
<= > >/span>
= > >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= > >e:

CVSR= > >OOT: >pan>/usr/cvs
Changes by: >ite-space: pre=3B"> jkrell at birch. >" style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= > >iles:
>> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 > class=3D"ecxApple-converted-space"> =3B
>xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= > >rc/unix/: m3makefile =3B >>
Removed files:
>space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= > >ignal.m3 =3B

Log= > > message:
>=3B"> updates so SPARC64_SOLARIS bootstrap can build
>=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= > >angent related to getting SPARC64_OPENBSD
>-span" style=3D"white-space: pre=3B"> to work -- problem apparently = > >with the floating point
>ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= > >s
>span>always TRUE=2C even for the first allocation=2C so
>cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= > >rying to garbage collect too
>=3D"white-space: pre=3B"> early=2C when self is still NULL)
>>


>ine">

> >= > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 17:43:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:43:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091214163101.109F61A2078@async.async.caltech.edu> References: <20091214134015.9044F2474001@birch.elegosoft.com>, , , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , , , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu>, , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: >> all DEC systems are little-endian Ok, educate me. VAX little endian? MIPS-based DecStations running Ultrix little endian? (again, MIPS ran NT, but MIPS is "well known" to be "either" there's often "mips" and "mipsle", "le"="little endian") Alpha/VMS little endian? Alpha/Tru64 little endian? IA64/VMS little endian? (IA64/HPUX little endian?) (Alpha/IA64/MIPS/PPC NT yes little all endian) - Jay > To: jay.krell at cornell.edu > Date: Mon, 14 Dec 2009 08:31:01 -0800 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Alpha is little-endian because it's DEC and all DEC systems are > little-endian. It's one of those religious wars, now long forgotten... > DEC did win that war, after all, but much good it did them. > > Also regarding Trestle: there are several tech reports about it that > explain the locking schemes in detail. Are there really other windowing > systems out there that have similarly good support for multithreaded > programs? (I've certainly never seen one...I think Trestle is very > very cool.) > > Mika > > Jay K writes: > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I assumed Alpha was little endian because it ran NT. > >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= > >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > > Linux and AIX?) > > > >Target.m3: > > > > (* big endian *) > > > > IF TextUtils.StartsWith(system=2C "PA") > > > > (* MIPS is definitely ambiguous! *) > > OR TextUtils.StartsWith(system=2C "MIPS") > > =20 > > (* PPC is a little ambiguous? *) > > OR TextUtils.StartsWith(system=2C "PPC") > > > > OR TextUtils.StartsWith(system=2C "SPARC") > > OR TextUtils.StartsWith(system=2C "SOL") THEN > > Little_endian :=3D FALSE=3B > > END=3B > > > >Anyway it shouldn't be hard to track down. > >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= > >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= > >ng around...) > > > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= > >s correct=2C and it /has/ no survived a fair number of combinations. I do c= > >ross builds /almost/ without considering host and target. Er=2C except you = > >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= > >as started hitting me more often... it's just something where the compiler = > >gets confused and does host math with target limitations=2C where it should= > > do target math. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 > >To: jay.krell at cornell.edu > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > > code. I rewrote it=2C at least once. > >Cross compiling works. > >Native does not. > >It must be the threshold variables in RTCollector. > > > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > > earliest use of FP in the run-time linker. If they are broken you find ou= > >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = > >one point just fine on native Alpha 64-bit=2C so should not be too hard to = > >fix. > >I really thought I understood that code. > > > > - Jay > > > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 > >To: jkrell at elego.de > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > >This suggests an m3cg backend compiler problem for floating point on SPARC6= > >4. > >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/12/14 14:40:15 > > > >Modified files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > > cm3/m3-libs/m3core/src/unix/: m3makefile=20 > >Removed files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > > > >Log message: > > updates so SPARC64_SOLARIS bootstrap can build > > (possible tangent related to getting SPARC64_OPENBSD > > to work -- problem apparently with the floating point > > constants in RTCollector=2C such that Behind() is > > always TRUE=2C even for the first allocation=2C so > > access violate trying to garbage collect too > > early=2C when self is still NULL) > > > > > > = > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= > >w=2C a lot of chips go either way these days (PowerPC little endian for NT = > >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?) >>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= > >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= > >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = > >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = > >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= > >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= > >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= > >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= > >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= > >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= > >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= > >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = > >has been sitting around...)

The code I put in parse.c is definitely = > >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = > >fair number of combinations. I do cross builds /almost/ without considering= > > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= > >obably fix that pretty soon as it has started hitting me more often... it's= > > just something where the compiler gets confused and does host math with ta= > >rget limitations=2C where it should do target math.

 =3B- Jay >>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= > >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> > > >
>parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= > >transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= > >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= > >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= > >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= > >te-space: normal=3B word-spacing: 0px=3B">
>rd=3B"> >te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= > >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= > >=2C at 10:43=2C Jay K wrote:
 >>

>interchange-newline">
>=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= > >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = > >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= > >mpiling works.
Native does not.
It must be the threshold variables in= > > RTCollector.

Yeah=2C I've= > > been bitten by just that scenario in the past -- those are the earliest us= > >e of FP in the run-time linker.  =3BIf they are broken you find out qui= > >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= > >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > > hard to fix.

>e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= > >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = > >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= > >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= > >ally thought I understood that code.

 =3B- Jay


>=3D"ecxstopSpelling">From: =3B= > >hosking at cs.purdue.edu >r>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To: >verted-space"> =3Bjkrell at eleg= > >o.de
CC: =3B >ref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= > >: Re: [M3commit] CVS Update: cm3

>le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= > >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= > >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= > >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= > >=3B word-spacing: 0px=3B"> >order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= > >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= > >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= > >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= > >px=3B">
>tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= > >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= > >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= > >al=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = > >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= > >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= > >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= > >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B"> >-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= > >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= > >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= > >ng: 0px=3B"> >: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= > >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= > >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= > >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= > >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= > >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= > >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B">
>Apple-style-span" style=3D"font-size: medium=3B"> >-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= > >ackend compiler problem for floating point on SPARC64.
<= > >/span>
= > >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= > >e:

CVSR= > >OOT: >pan>/usr/cvs
Changes by: >ite-space: pre=3B"> jkrell at birch. >" style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= > >iles:
>> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 > class=3D"ecxApple-converted-space"> =3B
>xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= > >rc/unix/: m3makefile =3B >>
Removed files:
>space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= > >ignal.m3 =3B

Log= > > message:
>=3B"> updates so SPARC64_SOLARIS bootstrap can build
>=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= > >angent related to getting SPARC64_OPENBSD
>-span" style=3D"white-space: pre=3B"> to work -- problem apparently = > >with the floating point
>ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= > >s
>span>always TRUE=2C even for the first allocation=2C so
>cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= > >rying to garbage collect too
>=3D"white-space: pre=3B"> early=2C when self is still NULL)
>>


>ine">

> >= > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 17:55:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 11:55:14 -0500 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: <951B9075-1A76-4A45-8A13-2E8B5A2AF277@cs.purdue.edu> Scheduler.Yield()? We allow programmers to disable preemptive thread scheduling with user-level threads and simply get yields at appropriate thread primitives (LOCK, Wait, etc.). If you have a loop like that with a non-preemptive user-level thread scheduler the only way to guarantee switching is to call Yield. On 14 Dec 2009, at 11:31, Jay K wrote: > Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). > It still seemed to hang. > (I realize you might not have meant that.) > > > So what happens if none of our user threads have any work? Is that possible? > Sure, I can make it so. > Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). > Will they actually wake up after that time? > And we won't spin the CPU in the meantime? > I guess I should test it out.. > > > I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. > But I wonder also..you have OpenBSD/x86 or sparc64? > cd to that test bed, make, ./tcontext. > It always seemed kind of jerky. > I bet it'll seem "faster" with "real" timer. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 10:39:31 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Main thread should call Yield if you want that behavior, not sleep. > > On 14 Dec 2009, at 14:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/14 14:57:30 > > Added files: > cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: > Makefile > config.c > context.c > context.h > m3makefile > tcontext.c > > Log message: > working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ > - This should be moved to m3core/src/thread/POSIX > - Notice how I switched from virtual timer to real timer, > in the test case that mimics m3core/src/thread/POSIX. > "This seems to work much better." > In particular, if the main thread does while (1) sleep(0) > to let things run, nothing runs. The virtual time doesn't > run down at all. If I make it a busy wait "while (1) ;" then > it does work. > > Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). > This solution might be preferred? Though it is slower to create a thread here, due to > extra gymnastics to establish the initial context. > > Also still some experiments to try. > _setjmp vs. setjmp vs. sigsetjmp. > Best is probably sigsetjmp(1). > using the same signal in both parts > > From hosking at cs.purdue.edu Mon Dec 14 17:56:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 11:56:30 -0500 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: <4AF3AD39-F883-49AD-BB49-6C26F11A69C0@cs.purdue.edu> On 14 Dec 2009, at 11:31, Jay K wrote: > Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). > It still seemed to hang. > (I realize you might not have meant that.) > > > So what happens if none of our user threads have any work? Is that possible? > Sure, I can make it so. > Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). > Will they actually wake up after that time? Good point. Depends on what the OS timer implementation will do. We may have threads blocked on IO too, but they will wake in the select call. > And we won't spin the CPU in the meantime? > I guess I should test it out.. > > > I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. > But I wonder also..you have OpenBSD/x86 or sparc64? > cd to that test bed, make, ./tcontext. > It always seemed kind of jerky. > I bet it'll seem "faster" with "real" timer. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 10:39:31 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Main thread should call Yield if you want that behavior, not sleep. > > On 14 Dec 2009, at 14:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/14 14:57:30 > > Added files: > cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: > Makefile > config.c > context.c > context.h > m3makefile > tcontext.c > > Log message: > working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ > - This should be moved to m3core/src/thread/POSIX > - Notice how I switched from virtual timer to real timer, > in the test case that mimics m3core/src/thread/POSIX. > "This seems to work much better." > In particular, if the main thread does while (1) sleep(0) > to let things run, nothing runs. The virtual time doesn't > run down at all. If I make it a busy wait "while (1) ;" then > it does work. > > Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). > This solution might be preferred? Though it is slower to create a thread here, due to > extra gymnastics to establish the initial context. > > Also still some experiments to try. > _setjmp vs. setjmp vs. sigsetjmp. > Best is probably sigsetjmp(1). > using the same signal in both parts > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:04:18 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:04:18 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <4B262845.1E75.00D7.1@scires.com> Jay, you should only see the "C" and "G" on POSIX platforms, not Windows. We could also change the behavior on POSIX to match Windows if everyone desires, or perhaps we could provide a switch capability to choose. --Randy >>> Jay K 12/13/2009 12:47 AM >>> I keep trying to understand Trestle but I keep failing. I tried to read the comments explaining how its locking works and I got lost quickly. I suspect that compares well to other GUI libraries in that they probably just don't do threading well. Easy to understand though. The Trestle apps are all pretty ugly and oddly behaved. Granted, I have no "real use" for them. I just exercise them a bit as test cases. I did notice you made the scrollbars look "nice" on Windows. The close box is marked "C". The grow box is marked "G". Yuck. As I said though, the more I look into Trestle, the more I think it is implementing a rather complete "windows system" and not just a library of widgets, nor even widgets + resizing algorithms. Nor even just widgets + resizing + event routing. Like, it seems to also manage clipping, knowing what needs redrawing, etc. But I'm not sure. It adds up to a lot of code, is my concern. That is good and bad. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:13:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:13:37 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: <4B262A74.1E75.00D7.1@scires.com> No, I think you misinterpret what I was trying to say. I did not make any changes affecting the way the GUI looks on POSIX. The changes were only on the Windows side to make the GUI look more like Windows. These changes were based on work that Critical Mass, Inc. performed under contract to my company. We have given these changes back to the M3 community by the work I did to integrate them into the then-current source tree. I have subsequently fixed a few bugs in the code over the past couple years. Regards, Randy >>> Tony Hosking 12/13/2009 1:30 PM >>> Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 18:12:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 12:12:33 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B262A74.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> <4B262A74.1E75.00D7.1@scires.com> Message-ID: So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. 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 14 Dec 2009, at 12:13, Randy Coleburn wrote: > No, I think you misinterpret what I was trying to say. > > I did not make any changes affecting the way the GUI looks on POSIX. > > The changes were only on the Windows side to make the GUI look more like Windows. These changes were based on work that Critical Mass, Inc. performed under contract to my company. We have given these changes back to the M3 community by the work I did to integrate them into the then-current source tree. > > I have subsequently fixed a few bugs in the code over the past couple years. > > Regards, > Randy > > >>> Tony Hosking 12/13/2009 1:30 PM >>> > Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. > > > On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > >> Jay: >> >> Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. >> >> Regards, >> Randy >> >> >>> Jay K 12/12/2009 10:41 PM >>> >> 2008-05-27 02:29 rcoleburn >> >> * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, >> vbtkitresources/close.ppm, vbtkitresources/down.ppm, >> vbtkitresources/grow.ppm, vbtkitresources/left.ppm, >> vbtkitresources/m3makefile, vbtkitresources/right.ppm, >> vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, >> lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, >> vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, >> lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, >> vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, >> vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: >> >> Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. >> >> >> Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? >> Can the work be redone against the 2008 versions? And factor out the common parts? >> >> I guess I should go and diff these against the 3.6 or 4.1 versions? >> And then apply those diffs to the Posix file to get the Win32 version? >> (Or again, try to share what is the same?) >> >> >> - Jay >> >> > Date: Sun, 13 Dec 2009 04:37:34 +0000 >> > To: m3commit at elegosoft.com >> > From: jkrell at elego.de >> > Subject: [M3commit] CVS Update: cm3 >> > >> > CVSROOT: /usr/cvs >> > Changes by: jkrell at birch. 09/12/13 04:37:34 >> > >> > Modified files: >> > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 >> > m3makefile >> > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 >> > ScrollerVBTClass.m3 >> > >> > Log message: >> > I forgot to mention: I'm really just guessing here. It seems to work. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:19:17 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:19:17 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> Message-ID: <4B262BC8.1E75.00D7.1@scires.com> >>> Olaf Wagner 12/14/2009 6:59 AM >>> >> >> I did notice you made the scrollbars look "nice" on Windows. >> >> The close box is marked "C". >> The grow box is marked "G". >I grant that making it look better would probably increase the user >acceptance. IMO there's no reason not to do that; but there hasn't been >anybody interested in working on it yet. Olaf, it would be easy to factor some of these appearance changes from the Windows-specific code back into the POSIX-specific code. I could do it, but we should first make sure everyone wants this type of behavior. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 18:36:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 17:36:56 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, <4B262A74.1E75.00D7.1@scires.com>, Message-ID: > So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. I did not. How many times I need to say I didn't touch the Posix code? We have posix/scroller and win32/scroller. win32/scroller is a copy/edit of posix/scroller. You can hypothetically compile either on either. It is all portable. To alter the appearance, they are different. In the code that made win32/scroller there was some crashing. I fixed that. To the extent that they are the same, I suggest the two files be merged into one, with "if"s. You know, like, you have approximately three choices in these things. Separate files, #if, and if. But with Modula-3, #if goes away. But you still have "if", depending on what the code looks like. If the branches are wildly divergent, for some definition of "wild", then separate files are appropriate. If the divergence is small, for some definition of "small", then "if" is preferable. Depending on the degree, "if" can be confusing. Too man ifs, hard to read the code fast and see what actually runs. Separate files obviously can lead to redundancy. In fact my first fix was to always use the Posix code. Since it worked and didn't crash. But then I fixed the crash instead. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 19:06:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 13:06:57 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, <4B262A74.1E75.00D7.1@scires.com>, Message-ID: <98166A57-C9AF-40E0-9F91-49AC4AE18ABB@cs.purdue.edu> OK, cool. :-) On 14 Dec 2009, at 12:36, Jay K wrote: > > So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. > > I did not. How many times I need to say I didn't touch the Posix code? > > > We have posix/scroller and win32/scroller. > win32/scroller is a copy/edit of posix/scroller. > You can hypothetically compile either on either. > It is all portable. > To alter the appearance, they are different. > In the code that made win32/scroller there was some crashing. > I fixed that. > > > To the extent that they are the same, I suggest the > two files be merged into one, with "if"s. > You know, like, you have approximately three choices > in these things. > Separate files, #if, and if. > But with Modula-3, #if goes away. > But you still have "if", depending on what the code looks like. > > > If the branches are wildly divergent, for some definition of "wild", > then separate files are appropriate. > If the divergence is small, for some definition of "small", > then "if" is preferable. > > > Depending on the degree, "if" can be confusing. > Too man ifs, hard to read the code fast and see what > actually runs. > Separate files obviously can lead to redundancy. > > > > In fact my first fix was to always use the Posix code. > Since it worked and didn't crash. > But then I fixed the crash instead. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Dec 14 19:12:56 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 14 Dec 2009 10:12:56 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20091214134015.9044F2474001@birch.elegosoft.com>, , , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , , , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu>, , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: <20091214181256.2AEDB1A2078@async.async.caltech.edu> Jay K writes: >--_dcd80a02-fc6b-42d8-93c7-943543066a21_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > >> all DEC systems are little-endian > >Ok=2C educate me. > > VAX little endian?=20 definitely > MIPS-based DecStations running Ultrix little endian?=20 > (again=2C MIPS ran NT=2C but MIPS is "well known" to be "either" there's= yes, definitely > often "mips" and "mipsle"=2C "le"=3D"little endian")=20 > Alpha/VMS little endian?=20 yes > Alpha/Tru64 little endian? =20 yes > IA64/VMS little endian? =20 no idea but I would suspect so > (IA64/HPUX little endian?) no idea > (Alpha/IA64/MIPS/PPC NT yes little all endian)=20 This was one of the things IBM and DEC used to send people out to flame each other over. How each is obviously superior to the other, "wrong-endian" system. This was a while ago.... Mika From peter.mckinna at gmail.com Tue Dec 15 01:27:27 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 15 Dec 2009 11:27:27 +1100 Subject: [M3devel] pickle bug..solved?.. not supposed to work? Message-ID: <3d9e5afc0912141627u2d9d2389k16544f95b815c36a@mail.gmail.com> I also vote for making V2 the default. I think the stubgen code has a hard coded setting making the protocol V1 somewhere. That would have to be fixed as well. Also there is a bunch of imports in various modules of the form Import Pickle2 as Pickle that would have to be changed. Also I have a couple of fixes for the ConvertPacking module for v2 that I should put in to do with 64-32 conversion. I think Blair MacIntyre did a lot of the extension for V2 and you see comments in the code where he has made various changes. I wonder what the etiquette is of removing those comments and leaving a reference to his work in header at the top? Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:01:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:01:55 +0000 Subject: [M3devel] RegisterFinalCleanup and locking? Message-ID: I think RegisterFinalCleanup should be augmented or changed so that caller can use it without holding a lock, thereby avoiding holding two locks (RegisterFinalCleanup uses heap lock) and worrying about the order/deadlock. Some sort of reserve/commit, reserve/cancel system. Like: cleanup := ReserveFinalCleanup(); (* can fail with exception*) cleanup.object := mutex; cleanup.function := CleanMutex; ... CommitFinalCleanup(cleanup); (* cannot fail *) or CancelFinalCleanup(cleanup); (* cannot fail *) I think it might not be at all difficult. Or: cleanup := ReserveFinalCleanup(); (* can fail with exception *) .. CommitFinalCleanup(cleanup, mutex, CleanMutex); or CancelFinalCleanup(cleanup); or: cleanup := ReserveFinalCleanup(mutex, CleanMutex); (* can fail with exception *) and then optional CancelFinalCleanup(cleanup); but not sure the last one is viable. Maybe: UnsafeCollectNow(mutex); ? Hm. Do we have that already? DISPOSE on traced references in unsafe code? And it does or does not handle the registered cleanup? I'll check. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:06:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:06:45 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? Message-ID: Is it possible to initialize mutexes and condition variables right away? Instead of having the delayed initialization? Mutex initialization is pretty fast on Windows, no syscall. Having it be delayed like it is maybe isn't worthwhile. As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? I know there is the idiom NEW(T).init() but that is up to callers to adhere to. Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:17:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:17:27 +0000 Subject: [M3devel] win32 conditionvariables Message-ID: I didn't realize it, but the Java code, now the Modula-3 code is the same as: http://www.cs.wustl.edu/~schmidt/win32-cv-1.html "3.3. The Generation Count Solution" including the downsides he lists -- some unfairness. Now that I notice the similarity, I'll compare against this one as well. And maybe "rewrite" in Modula-3 instead of the current C. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 04:49:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 22:49:48 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: Message-ID: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) On 14 Dec 2009, at 22:06, Jay K wrote: > Is it possible to initialize mutexes and condition variables right away? > Instead of having the delayed initialization? > > > Mutex initialization is pretty fast on Windows, no syscall. > Having it be delayed like it is maybe isn't worthwhile. > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > - Jay > From jay.krell at cornell.edu Tue Dec 15 05:04:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:04:17 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: Is it possible to do on Win32? Win32 critical sections are cheap and already probably work roughly "that way". Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. Our (new) win32 condition variables are not cheap, but similar in cost to Java. (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 22:49:48 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > Is it possible to initialize mutexes and condition variables right away? > > Instead of having the delayed initialization? > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 05:18:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:18:22 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu>, Message-ID: ps: maybe we can hope for the folks under us implementing pthread_mutex and criticalsection to do a very good job? We have much more context?? Inlining?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 15 Dec 2009 04:04:17 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? Is it possible to do on Win32? Win32 critical sections are cheap and already probably work roughly "that way". Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. Our (new) win32 condition variables are not cheap, but similar in cost to Java. (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 22:49:48 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > Is it possible to initialize mutexes and condition variables right away? > > Instead of having the delayed initialization? > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 05:26:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 23:26:43 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: We need an compiler intrinsic CAS to avoid calls. More incentive to get the gcc-based backend working on Windows? I'll bet most modern Java implementations destroy thread libraries on performance. In the uncontended case they have no atomic operations, and the code is all inline. I'm not sure what Java implementation you are looking at... (Hotspot's sucks BTW). On 14 Dec 2009, at 23:04, Jay K wrote: > Is it possible to do on Win32? > Win32 critical sections are cheap and already probably work roughly "that way". > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > - Jay > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > From: hosking at cs.purdue.edu > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > Is it possible to initialize mutexes and condition variables right away? > > > Instead of having the delayed initialization? > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > - Jay > > > > > From hosking at cs.purdue.edu Tue Dec 15 05:39:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 23:39:08 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> So, the basic scenario is as follows. Briefly... We should ditch signals as a mechanism for stopping threads. The compiler should inject a "safe-point" at each procedure call and backward branch. At safe-points, the thread polls a thread-local to see if the run-time system needs it to step out-of-line for some reason. At calls to <*EXTERNAL*> procedures we set a thread-local to say the thread is stepping outside Modula-3 code, with corresponding synchronized test on return in case the run-time needs it to pay attention. Now, when a MUTEX is first acquired, we simply CAS in a bit in the MUTEX along with the acquiring thread's ID. That thread can then release and acquire as often as it likes, no further CAS, no pthread_mutex_lock. Acquirers must always CAS to see if the bit is set. If it is then the lock is reserved for some other thread. We must revoke the reservation by handshake (as described above) with the reserving thread. We then inflate a real pthread_mutex_lock along with any queues needed for the MUTEX/CV. The handshake mechanism can also be used for stopping threads for GC, etc. The point is that uncontended locks should cost almost nothing. On 14 Dec 2009, at 23:04, Jay K wrote: > Is it possible to do on Win32? > Win32 critical sections are cheap and already probably work roughly "that way". > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > - Jay > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > From: hosking at cs.purdue.edu > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > Is it possible to initialize mutexes and condition variables right away? > > > Instead of having the delayed initialization? > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > - Jay > > > > > From jay.krell at cornell.edu Tue Dec 15 05:47:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:47:33 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> , Message-ID: Yes HotSpot. I guess I should look at others and JITed code. C# too. So, question..Java probably has to perf because people probably abuse it. They have to counteract deficiencies elsewhere. Similar for us? Granted, I removed the win32 thread cache. And there was a criticalsection cache in the past. No function call or interlock in uncontended is impressive..you could do that based on the Hotspot code..but is it worth..the inlining bloat and "dependencies" (changes requiring recompiling clients). The gcc backend does work on Windows. In a fashion, a fairly practical fashion. With "mingw" you can just go and configure && make and you get a gcc that doesn't use cygwin. I'm more interested in improving the fast integrated one, or maybe llvm support. Something that writes out .obj files and doesn't require so many processes. Debugging is a mixed story too. Integrated backend outputs only function symbols and line number. Nothing for locals or types. gcc output I believe debuggable only with gdb, at least the cygwin gcc. We can get CAS et. al. without resorting to gcc. As a function call or probably inline. I think that locks in a dependency on newer processors and/or operating systems though. If the integrated backend is missing CAS and that is holding you up, speak up. The integrated backend is just incredibly faster than the gcc backend, both to build and run. - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 23:26:43 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We need an compiler intrinsic CAS to avoid calls. More incentive to get the gcc-based backend working on Windows? > I'll bet most modern Java implementations destroy thread libraries on performance. In the uncontended case they have no atomic operations, and the code is all inline. I'm not sure what Java implementation you are looking at... (Hotspot's sucks BTW). > > On 14 Dec 2009, at 23:04, Jay K wrote: > > > Is it possible to do on Win32? > > Win32 critical sections are cheap and already probably work roughly "that way". > > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > > > - Jay > > > > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > > From: hosking at cs.purdue.edu > > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > > CC: m3devel at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > > > Is it possible to initialize mutexes and condition variables right away? > > > > Instead of having the delayed initialization? > > > > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 06:13:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 05:13:22 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> References: , , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu>, , <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> Message-ID: > That thread can then release and acquire as often as it likes, no further CAS, no > pthread_mutex_lock. Acquirers must always CAS to see if the bit is set How does the thread know it doesn't need to CAS? With a non-atomic check? > polls a thread-local Expensive currently. Can be improved a la gcc __thread, Win32 __declspec(thread), but with limits. __declspec(thread) doesn't work pre-Vista with .dlls loaded "after" the .exe. You can detect that though and switch between two paths. The "reserved" parameter to DllMain tells you if you are loaded in CreateProcess or LoadLibrary, and therefore if __declspec(thread) works pre-Vista or if you need to use TlsAlloc/TlsGetValue. You wouldn't want to inline that though, so "poll a thread local" is a function call. If there are multiple backward branches in a function, you can optimize by remembering the address of the thread local in a "normal" local, certainly. You can also possibly..I haven't thought this through, but I think for each function you can generate two entry points. Call them "internal" and "external". "internal" takes an extra pointer, the pointer to the thread locals. "external" gets the thread locals in an expensive fashion (above) and calls "internal". If a function doesn't actually need the thread locals, the two are aliased to each other. Within a module (a single .m3 file), you always call internal, or maybe within a library/dll, or maybe within Modula-3 entirely. But callbacks or direct calls from C go to external. Though callbacks can do better. Even C calls could do better, if you can break the C/Modula-3 ABI. I'm not sure this overall scheme works out, but I think it does. This is similar to how in some systems exported functions are duplicated. The exported version retrieves the base pointer for the .dll's data and then calls the non-exported one. NT/PPC, NT/IA64, I think Mac/CFM/PPC and others work this way. I believe it helps achieve position independence, all static data is accessed via a register that is maintained for all entry and/or exit from a .dll. > calls to <*EXTERNAL*> procedures Arguably we can do whatever needed in our .c code. You know, since <*external*> is now largely but not completely implemented by us. I realize there's still e.g. X/Windows, OpenGL, Win32. Only "libc" is wrapped aggressively right now, and others are large. And maybe that is all that should be, e.g. OpenGL and Xlib are very portable and so maybe cloning their headers is too? - Jay > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 23:39:08 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > So, the basic scenario is as follows. Briefly... We should ditch signals as a mechanism for stopping threads. The compiler should inject a "safe-point" at each procedure call and backward branch. At safe-points, the thread polls a thread-local to see if the run-time system needs it to step out-of-line for some reason. At calls to <*EXTERNAL*> procedures we set a thread-local to say the thread is stepping outside Modula-3 code, with corresponding synchronized test on return in case the run-time needs it to pay attention. Now, when a MUTEX is first acquired, we simply CAS in a bit in the MUTEX along with the acquiring thread's ID. That thread can then release and acquire as often as it likes, no further CAS, no pthread_mutex_lock. Acquirers must always CAS to see if the bit is set. If it is then the lock is reserved for some other thread. We must revoke the reservation by handshake (as described above) with the reserving thread. We then inflate a real pthread_mutex_lock along with any queues needed for the MUTEX/CV. The handshake mechanism can also be used for stopping threads for GC, etc. > > The point is that uncontended locks should cost almost nothing. > > On 14 Dec 2009, at 23:04, Jay K wrote: > > > Is it possible to do on Win32? > > Win32 critical sections are cheap and already probably work roughly "that way". > > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > > > - Jay > > > > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > > From: hosking at cs.purdue.edu > > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > > CC: m3devel at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > > > Is it possible to initialize mutexes and condition variables right away? > > > > Instead of having the delayed initialization? > > > > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 15 11:42:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Dec 2009 11:42:47 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B262FC7.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> Message-ID: <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > Can you supply me with SRC Report 159 ? > > The link you give doesn't seem to know how to serve up the report. Strange. I had no problem to download it there. I'll CC m3devel in case anybody else cannot get it. Olaf > I would like to better understand the locking level pragmas. > > Regards, > Randy > >>>> Olaf Wagner 12/14/2009 6:59 AM >>> > Quoting Jay K : > >> I keep trying to understand Trestle but I keep failing. >> I tried to read the comments explaining how its locking >> works and I got lost quickly. > > Actually the Trestle locking was `verified' after the implementation > was finished with the Extended Statical Checker written at that time > in Modula-3, too (but reimplemented since then in Java). See > SRC report 159, for example here: > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 > > This is where all the locking level pragmas come from. > >> I suspect that compares well to other GUI libraries >> in that they probably just don't do threading well. > > I always thought that using threads extensively to keep the > application > responding to user request was one of the strong areas of Testle. > >> Easy to understand though. >> >> The Trestle apps are all pretty ugly and oddly behaved. >> Granted, I have no "real use" for them. I just exercise >> them a bit as test cases. >> >> I did notice you made the scrollbars look "nice" on Windows. >> >> The close box is marked "C". >> The grow box is marked "G". > > I grant that making it look better would probably increase the user > acceptance. IMO there's no reason not to do that; but there hasn't > been > anybody interested in working on it yet. > >> Yuck. >> >> As I said though, the more I look into Trestle, the more I think >> it is implementing a rather complete "windows system" and not >> just a library of widgets, nor even widgets + resizing algorithms. >> Nor even just widgets + resizing + event routing. >> >> Like, it seems to also manage clipping, knowing what needs >> redrawing, etc. >> >> But I'm not sure. >> >> It adds up to a lot of code, is my concern. >> >> That is good and bad. > > Yes. But it's a huge project to integrate another GUI library into M3 > and make it as useful as Trestle. > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: SRC-report-159.pdf Type: application/pdf Size: 197231 bytes Desc: not available URL: From hendrik at topoi.pooq.com Tue Dec 15 15:08:46 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Dec 2009 09:08:46 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> Message-ID: <20091215140846.GA12996@topoi.pooq.com> On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: > So, the basic scenario is as follows. Briefly... We should ditch > signals as a mechanism for stopping threads. The compiler should > inject a "safe-point" at each procedure call and backward branch. At > safe-points, the thread polls a thread-local to see if the run-time > system needs it to step out-of-line for some reason. ... ... > > The point is that uncontended locks should cost almost nothing. Nothing? All those safe-points cost time, don't they, even when no locks are being used at all? Is this analogous to charging everyone for the overhead involved in recursion, even when no recursion is being used? -- hendrik From mika at async.async.caltech.edu Tue Dec 15 16:02:14 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 15 Dec 2009 07:02:14 -0800 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215140846.GA12996@topoi.pooq.com> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> Message-ID: <20091215150214.D4E8D1A207A@async.async.caltech.edu> What's the main problem you guys are trying to solve? In my experience the biggest performance loss in moving from PM3 user threads to CM3 pthreads has been with programs that lock a lot but are actually not using the thread-safety for anything. Those programs would be improved greatly by a scheme such as the one Tony describes, where a mutex is "passed" between the threads, with "real locking" only when it has to be passed from one locker to another, not when a single locker locks and re-locks the mutex. But I don't see how that implies a need to change the thread-stopping mechanism.... it's something else, I take it? Mika hendrik at topoi.pooq.com writes: >On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >> So, the basic scenario is as follows. Briefly... We should ditch >> signals as a mechanism for stopping threads. The compiler should >> inject a "safe-point" at each procedure call and backward branch. At >> safe-points, the thread polls a thread-local to see if the run-time >> system needs it to step out-of-line for some reason. > >... >... >> >> The point is that uncontended locks should cost almost nothing. > >Nothing? All those safe-points cost time, don't they, even when no >locks are being used at all? > >Is this analogous to charging everyone for the overhead involved in >recursion, even when no recursion is being used? > >-- hendrik From hosking at cs.purdue.edu Tue Dec 15 16:18:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 10:18:17 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215140846.GA12996@topoi.pooq.com> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> Message-ID: Yes, good point. It really is a question of how much does the safe-point check cost. Perhaps for a "systems" language like Modula-3 it is important that we not tax code that doesn't use threads or locks. But in today's world code like that is less common, no? And Modula-3 positively encourages them. On the other hand, Modula-3 demands programmers explicitly declare their locks (unlike Java which says any object can be a lock or CV), so perhaps retaining the referential transparency of explicit locks (you don't pay unless you use them) is more in the Modula-3 "systems" programming way of thinking. There are other ways to do the safe-points. One could "poison" (access-protect) a page that the thread simply reads a location from at the safe-points, whereupon it will trap. But in some experiments we have done with Java, it is more important that the thread simply ack, rather than having actually to take a trap and come to a screeching halt in a signal handler. And, since most threads are usually blocked or executing some external system call, you don't even have to wait for the ack. On 15 Dec 2009, at 09:08, hendrik at topoi.pooq.com wrote: > On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >> So, the basic scenario is as follows. Briefly... We should ditch >> signals as a mechanism for stopping threads. The compiler should >> inject a "safe-point" at each procedure call and backward branch. At >> safe-points, the thread polls a thread-local to see if the run-time >> system needs it to step out-of-line for some reason. > > ... > ... >> >> The point is that uncontended locks should cost almost nothing. > > Nothing? All those safe-points cost time, don't they, even when no > locks are being used at all? > > Is this analogous to charging everyone for the overhead involved in > recursion, even when no recursion is being used? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 16:24:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 10:24:48 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215150214.D4E8D1A207A@async.async.caltech.edu> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> <20091215150214.D4E8D1A207A@async.async.caltech.edu> Message-ID: On 15 Dec 2009, at 10:02, Mika Nystrom wrote: > What's the main problem you guys are trying to solve? > > In my experience the biggest performance loss in moving from PM3 user > threads to CM3 pthreads has been with programs that lock a lot but are > actually not using the thread-safety for anything. Exactly. In "uniprocessor" user-threading, lock is simply INC(inCritical)/DEC(inCritical), which controls whether threads can switch or not. > Those programs would be improved greatly by a scheme such as the one > Tony describes, where a mutex is "passed" between the threads, with > "real locking" only when it has to be passed from one locker to another, > not when a single locker locks and re-locks the mutex. > > But I don't see how that implies a need to change the thread-stopping > mechanism.... it's something else, I take it? We could use a CAS on every acquire/release, implementing the Thin Locks technique mentioned in one of the papers I cited. I wanted to go one step more, to avoid the CAS (which has overhead beyond a simple load/store) by allowing a lock to be reserved to one thread the first time it is acquired. That thread gets to acquire/release without CAS. When another thread comes along and wants the lock it needs a mechanism to revoke the reservation. That's why we need the handshake mechanism. I could use the current signal-based approach, but that has the nasty effect of stopping the target thread in its tracks. Better that it simply ack the revocation and then keep running. > Mika > > hendrik at topoi.pooq.com writes: >> On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >>> So, the basic scenario is as follows. Briefly... We should ditch >>> signals as a mechanism for stopping threads. The compiler should >>> inject a "safe-point" at each procedure call and backward branch. At >>> safe-points, the thread polls a thread-local to see if the run-time >>> system needs it to step out-of-line for some reason. >> >> ... >> ... >>> >>> The point is that uncontended locks should cost almost nothing. >> >> Nothing? All those safe-points cost time, don't they, even when no >> locks are being used at all? >> >> Is this analogous to charging everyone for the overhead involved in >> recursion, even when no recursion is being used? >> >> -- hendrik From rodney_bates at lcwb.coop Tue Dec 15 22:23:50 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 15 Dec 2009 15:23:50 -0600 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> Message-ID: <4B27FE66.5010600@lcwb.coop> Olaf Wagner wrote: > Quoting Randy Coleburn : > >> Olaf: >> >> Can you supply me with SRC Report 159 ? >> >> The link you give doesn't seem to know how to serve up the report. I got some kind of permission failure when trying to get it via http: http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-159.ps.gz I manually edited the 'http' to 'ftp' and got it without trouble. I could also use ftp to see a listing of the parent directory, with all the SRC reports. > > Strange. I had no problem to download it there. > I'll CC m3devel in case anybody else cannot get it. > > Olaf > >> I would like to better understand the locking level pragmas. >> >> Regards, >> Randy >> >>>>> Olaf Wagner 12/14/2009 6:59 AM >>> >> Quoting Jay K : >> >>> I keep trying to understand Trestle but I keep failing. >>> I tried to read the comments explaining how its locking >>> works and I got lost quickly. >> >> Actually the Trestle locking was `verified' after the implementation >> was finished with the Extended Statical Checker written at that time >> in Modula-3, too (but reimplemented since then in Java). See >> SRC report 159, for example here: >> >> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 >> >> This is where all the locking level pragmas come from. >> >>> I suspect that compares well to other GUI libraries >>> in that they probably just don't do threading well. >> >> I always thought that using threads extensively to keep the >> application >> responding to user request was one of the strong areas of Testle. >> >>> Easy to understand though. >>> >>> The Trestle apps are all pretty ugly and oddly behaved. >>> Granted, I have no "real use" for them. I just exercise >>> them a bit as test cases. >>> >>> I did notice you made the scrollbars look "nice" on Windows. >>> >>> The close box is marked "C". >>> The grow box is marked "G". >> >> I grant that making it look better would probably increase the user >> acceptance. IMO there's no reason not to do that; but there hasn't >> been >> anybody interested in working on it yet. >> >>> Yuck. >>> >>> As I said though, the more I look into Trestle, the more I think >>> it is implementing a rather complete "windows system" and not >>> just a library of widgets, nor even widgets + resizing algorithms. >>> Nor even just widgets + resizing + event routing. >>> >>> Like, it seems to also manage clipping, knowing what needs >>> redrawing, etc. >>> >>> But I'm not sure. >>> >>> It adds up to a lot of code, is my concern. >>> >>> That is good and bad. >> >> Yes. But it's a huge project to integrate another GUI library into M3 >> and make it as useful as Trestle. >> >> Olaf From peter.mckinna at gmail.com Wed Dec 16 02:13:30 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Wed, 16 Dec 2009 12:13:30 +1100 Subject: [M3devel] Hard real time Message-ID: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Hi, Is there any way to use the realtime options of pthreads, to set the scheduler and the mutex protocols for priority inherit etc, all that good stuff in an M3 program? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 02:18:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 20:18:53 -0500 Subject: [M3devel] Hard real time In-Reply-To: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Message-ID: <785B08D1-2A2E-4202-8D67-132C6D0E21A7@cs.purdue.edu> It would be possible if we supported APIs for that. On 15 Dec 2009, at 20:13, Peter McKinna wrote: > Hi, > > Is there any way to use the realtime options of pthreads, to set the scheduler and the mutex protocols for priority inherit etc, all that good stuff in an M3 program? > > Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 16 10:35:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 10:35:35 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B27FE66.5010600@lcwb.coop> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> <4B27FE66.5010600@lcwb.coop> Message-ID: <20091216103535.ufbvdqddb0gwgc08@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Olaf Wagner wrote: >> Quoting Randy Coleburn : >> >>> Olaf: >>> >>> Can you supply me with SRC Report 159 ? >>> >>> The link you give doesn't seem to know how to serve up the report. > I got some kind of permission failure when trying to get it via http: > > http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-159.ps.gz > > I manually edited the 'http' to 'ftp' and got it without trouble. I could > also use ftp to see a listing of the parent directory, with all the SRC > reports. So gatekeeper is still online :-) I wonder if I should ask Greg Nelson if we could get the M3 code for ESC... but it's probably not going to be(come) open source, as it has been ported to Java since and may well be commercially used. It would be great if we had such a tool for CM3 though. 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 From wagner at elegosoft.com Wed Dec 16 10:39:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 10:39:06 +0100 Subject: [M3devel] Hard real time In-Reply-To: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Message-ID: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Quoting Peter McKinna : > Hi, > > Is there any way to use the realtime options of pthreads, to set the > scheduler and the mutex protocols for priority inherit etc, all that good > stuff in an M3 program? I don't know of such an interface, but it would be great if we had it. Is this stuff pthread standard, or more or less system dependent? 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 From jay.krell at cornell.edu Wed Dec 16 11:35:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 10:35:42 +0000 Subject: [M3devel] Hard real time In-Reply-To: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com>, <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Message-ID: search the web for: "setthreadpriority" "opengroup sched.h" http://www.opengroup.org/onlinepubs/007908799/xsh/sched.h.html http://msdn.microsoft.com/en-us/library/ms686277(VS.85).aspx etc. Would be good to abstract out something that can be done over pthreads and Win32 and possibly user threads. As I understand, "hard real time" is rare. You know, when page faults occur cannot be unpredictable and still be hard real time, right? "rough scheduling parameters", sure, but not "hard real time". You could also ignore Win32 and user threads and drop down into C and party on pthread_self(). That is, the key is coming up with portable interfaces and interface "policing". - Jay > Date: Wed, 16 Dec 2009 10:39:06 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hard real time > > Quoting Peter McKinna : > > > Hi, > > > > Is there any way to use the realtime options of pthreads, to set the > > scheduler and the mutex protocols for priority inherit etc, all that good > > stuff in an M3 program? > > I don't know of such an interface, but it would be great if we had > it. Is this stuff pthread standard, or more or less system dependent? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 11:39:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 10:39:34 +0000 Subject: [M3devel] Hard real time In-Reply-To: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com>, <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Message-ID: (We should port to QNX and VxWorks?) :) - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] Hard real time Date: Wed, 16 Dec 2009 10:35:42 +0000 search the web for: "setthreadpriority" "opengroup sched.h" http://www.opengroup.org/onlinepubs/007908799/xsh/sched.h.html http://msdn.microsoft.com/en-us/library/ms686277(VS.85).aspx etc. Would be good to abstract out something that can be done over pthreads and Win32 and possibly user threads. As I understand, "hard real time" is rare. You know, when page faults occur cannot be unpredictable and still be hard real time, right? "rough scheduling parameters", sure, but not "hard real time". You could also ignore Win32 and user threads and drop down into C and party on pthread_self(). That is, the key is coming up with portable interfaces and interface "policing". - Jay > Date: Wed, 16 Dec 2009 10:39:06 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hard real time > > Quoting Peter McKinna : > > > Hi, > > > > Is there any way to use the realtime options of pthreads, to set the > > scheduler and the mutex protocols for priority inherit etc, all that good > > stuff in an M3 program? > > I don't know of such an interface, but it would be great if we had > it. Is this stuff pthread standard, or more or less system dependent? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 13:37:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 12:37:38 +0000 Subject: [M3devel] providing "bootstrap" archives Message-ID: jay at xlin2:/dev2/cm3/scripts/python$ ls -l *gz -rw-r--r-- 1 jay jay 5002815 2009-12-16 04:15 cm3-boot-AMD64_FREEBSD-1.tar.gz -rw-r--r-- 1 jay jay 5004281 2009-12-16 04:30 cm3-boot-AMD64_OPENBSD-1.tar.gz -rw-r--r-- 1 jay jay 5225719 2009-12-16 03:45 cm3-boot-I386_DARWIN-1.tar.gz -rw-r--r-- 1 jay jay 4471845 2009-12-16 03:59 cm3-boot-I386_OPENBSD-1.tar.gz -rw-r--r-- 1 jay jay 5356193 2009-12-16 03:29 cm3-boot-PPC_DARWIN-1.tar.gz -rw-r--r-- 1 jay jay 5506665 2009-12-16 03:29 cm3-boot-PPC_LINUX-1.tar.gz -rw-r--r-- 1 jay jay 4871443 2009-12-16 03:05 cm3-boot-SPARC32_LINUX-1.tar.gz jay at xlin2:/dev2/cm3/scripts/python$ cat 1.sh for a in PPC_LINUX PPC_DARWIN I386_DARWIN I386_OPENBSD AMD64_FREEBSD \ AMD64_OPENBSD AMD64_LINUX AMD64_DARWIN SOLsun SOLgnu \ SPARC64_OPENBSD SPARC32_LINUX SPARC64_SOLARIS MIPS64_OPENBSD; do ./boot1.py $a done Possibly we should be running that in Hudson or something, on one or more machines? I believe there's one problem running it on 64 bit hosts. I'll fix that soon. These archives, copied to the target machine that contains cc/make/ld, possibly with a little bit of Makefile editing, can build cm3. And then from there you can build everything else. A bunch of cm3cg result too that maybe should be distributed somehow/somewhere. Probably "-1" should be changed to a real version/date. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 16 13:57:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 13:57:20 +0100 Subject: [M3devel] providing "bootstrap" archives In-Reply-To: References: Message-ID: <20091216135720.a5b46rhbzq8o400c@mail.elegosoft.com> Quoting Jay K : > > jay at xlin2:/dev2/cm3/scripts/python$ ls -l *gz > -rw-r--r-- 1 jay jay 5002815 2009-12-16 04:15 cm3-boot-AMD64_FREEBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5004281 2009-12-16 04:30 cm3-boot-AMD64_OPENBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5225719 2009-12-16 03:45 cm3-boot-I386_DARWIN-1.tar.gz > -rw-r--r-- 1 jay jay 4471845 2009-12-16 03:59 cm3-boot-I386_OPENBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5356193 2009-12-16 03:29 cm3-boot-PPC_DARWIN-1.tar.gz > -rw-r--r-- 1 jay jay 5506665 2009-12-16 03:29 cm3-boot-PPC_LINUX-1.tar.gz > -rw-r--r-- 1 jay jay 4871443 2009-12-16 03:05 cm3-boot-SPARC32_LINUX-1.tar.gz > > > jay at xlin2:/dev2/cm3/scripts/python$ cat 1.sh > for a in PPC_LINUX PPC_DARWIN I386_DARWIN I386_OPENBSD AMD64_FREEBSD \ > AMD64_OPENBSD AMD64_LINUX AMD64_DARWIN SOLsun SOLgnu \ > SPARC64_OPENBSD SPARC32_LINUX SPARC64_SOLARIS MIPS64_OPENBSD; do > ./boot1.py $a > done > > Possibly we should be running that in Hudson or something, on one or > more machines? Great! We should definitely add that to the Hudson jobs. I'm far behind there and hope to be able to do something during the Christmas break. It would be great if we could finish the release though and use the Hudson jobs for the trunk. There are not enough resources currently to do both, at least not on my or Elego's systems. Olaf > I believe there's one problem running it on 64 bit hosts. > > I'll fix that soon. > > These archives, copied to the target machine that contains > cc/make/ld, possibly > > with a little bit of Makefile editing, can build cm3. > > And then from there you can build everything else. > > > > > > A bunch of cm3cg result too that maybe should be distributed > somehow/somewhere. > > > > > > Probably "-1" should be changed to a real version/date. > > > > - Jay > -- 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 From jay.krell at cornell.edu Wed Dec 16 14:05:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 13:05:38 +0000 Subject: [M3devel] email hiccup Message-ID: Mail to me will see bounces but it does get through. I'm working on it. (see -- it gets forwarded to two places, one that I read, and one that is bouncing..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 16:36:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 15:36:24 +0000 Subject: [M3devel] pthread/Interix Message-ID: [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 16:40:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 15:40:04 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: References: Message-ID: (verified that empty records are of zero size; in C++ that's a not always possible optimization, they often have a filler byte, in order to generate unique addresses in places.) From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Wed, 16 Dec 2009 15:36:24 +0000 Subject: [M3devel] pthread/Interix [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 17:40:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 11:40:56 -0500 Subject: [M3devel] pthread/Interix In-Reply-To: References: Message-ID: <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote: > [again, expect a bounce, but the mail does get through] > > > Tony, for Interix, suspend/resume thread can be achieved writing to a file. > Getting a suspended thread's registers can be gotten reading from a file. > (I believe the same thing works on Solaris.) > It appears to be intended for debuggers. > I can see that it works well. > I doubt that a thread's context is on a signal handler's stack. > I propose: > > > ActState = { Starting, Started, Stopping, Stopped }; > REVEAL Activation = UNTRACED BRANDED REF RECORD > frame: ADDRESS := NIL; (* exception handling support *) > handle: pthread_t := NIL; (* LL = activeMu; thread handle *) > statusFile: int := -1; (* for Interix *) > controlFile: int := -1; (* for Interix *) > (* C code knows the structure above this point *) > ... > END; > > > ThreadPThread.h: > > > typedef struct _Activation_t { > void* frame; > void* pthread; > int statusFile; /* for Interix */ > int controlFile; /* for Interix */ > } Activation_t; > > > and then whereever we pass act.handle off to C code, pass act instead. > > > frame is kept first so that it is offset 0 in case that gives codegen efficiencies > on the often used push/popframe. > The other three are moved up to the top to reduce maintainence of ThreadPThread.h. > > > I assume "branding" doesn't introduce data in the record. > I'd have to check the codegen to verify frame is at offset 0. > > > #ifdef code will open the files. > Modula-3 code can check if the files are >= 0 and close them, > or it can be a call out to #ifdefed C. > > > An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. > (as VAR for initialization). > That is less fragile and less extensible. > I'm fine with that approach too. > > > As well though, I was wondering, maybe we should have: > > > common/InterixThreadState.i3 > T = RECORD END; (* zero size? *) > > > interix/InterixThreadState.i3 > T = RECORD statusFile, controlFile := -1; END; > > > and then put InterixThreadState.T in Activation. > That way saving the other platforms from spending the space. > Just two integers, not much, but in principle.. > (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, > on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) > > > I could also open/close the files for every suspend/resume/processStopped, > though that seems too lame. > > > Another idea, that I don't really like, is to never optimize and > ignore the registers and just use the stack. > I rarely optimize, but depending on that seems bad. > > > Your "safe points" proposal would also make this work, though > I'd rather not wait for that. > > > ? > > Ok to add the two integers all the time? > Ok to either depend on the record layout in C, or to always pass the integers around? > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 17:49:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 16:49:52 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> Message-ID: Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. There is only single parameter signal handlers. Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. That is what is particularly unfortunate. I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 11:40:56 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote: [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 18:08:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 12:08:09 -0500 Subject: [M3devel] pthread/Interix In-Reply-To: References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> Message-ID: <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> On 16 Dec 2009, at 11:49, Jay K wrote: > Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. Interesting, this is exactly the way Mach does signals (which is why we use the Mach suspend/resume primitives for Darwin/OSX). If that is how they work, then can't you use the suspend/resume primitives directly? > There is only single parameter signal handlers. > > Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. > That is what is particularly unfortunate. > > I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. > > An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. > > (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) > > - Jay > > > Subject: Re: pthread/Interix > From: hosking at cs.purdue.edu > Date: Wed, 16 Dec 2009 11:40:56 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I really dislike this... just for a broken platform... > > Is there really no way to know that the context on is not on the stack somewhere? > > On 16 Dec 2009, at 10:36, Jay K wrote: > > [again, expect a bounce, but the mail does get through] > > > Tony, for Interix, suspend/resume thread can be achieved writing to a file. > Getting a suspended thread's registers can be gotten reading from a file. > (I believe the same thing works on Solaris.) > It appears to be intended for debuggers. > I can see that it works well. > I doubt that a thread's context is on a signal handler's stack. > I propose: > > > ActState = { Starting, Started, Stopping, Stopped }; > REVEAL Activation = UNTRACED BRANDED REF RECORD > frame: ADDRESS := NIL; (* exception handling support *) > handle: pthread_t := NIL; (* LL = activeMu; thread handle *) > statusFile: int := -1; (* for Interix *) > controlFile: int := -1; (* for Interix *) > (* C code knows the structure above this point *) > ... > END; > > > ThreadPThread.h: > > > typedef struct _Activation_t { > void* frame; > void* pthread; > int statusFile; /* for Interix */ > int controlFile; /* for Interix */ > } Activation_t; > > > and then whereever we pass act.handle off to C code, pass act instead. > > > frame is kept first so that it is offset 0 in case that gives codegen efficiencies > on the often used push/popframe. > The other three are moved up to the top to reduce maintainence of ThreadPThread.h. > > > I assume "branding" doesn't introduce data in the record. > I'd have to check the codegen to verify frame is at offset 0. > > > #ifdef code will open the files. > Modula-3 code can check if the files are >= 0 and close them, > or it can be a call out to #ifdefed C. > > > An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. > (as VAR for initialization). > That is less fragile and less extensible. > I'm fine with that approach too. > > > As well though, I was wondering, maybe we should have: > > > common/InterixThreadState.i3 > T = RECORD END; (* zero size? *) > > > interix/InterixThreadState.i3 > T = RECORD statusFile, controlFile := -1; END; > > > and then put InterixThreadState.T in Activation. > That way saving the other platforms from spending the space. > Just two integers, not much, but in principle.. > (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, > on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) > > > I could also open/close the files for every suspend/resume/processStopped, > though that seems too lame. > > > Another idea, that I don't really like, is to never optimize and > ignore the registers and just use the stack. > I rarely optimize, but depending on that seems bad. > > > Your "safe points" proposal would also make this work, though > I'd rather not wait for that. > > > ? > > Ok to add the two integers all the time? > Ok to either depend on the record layout in C, or to always pass the integers around? > > > Thanks, > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 18:40:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 17:40:52 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> , <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> Message-ID: There are no public suspend/resume primitives exposed. You can see in the debugger what happens. The signal handling thread calls NtSuspendThread/NtResumeThread. I suppose there is a chance they use the target thread's stack to hold the full previous context, I can dig in the debugger and see. I don't think what I have is too awful though. You see the test_interix.c file? I believe Cygwin does similar, though in that case the thread probably doesn't have the constrained access and you can use the public Win32 GetCurrentThread/DuplicateHandle/SuspendThread/ResumeThread functions. Remember how I had that turning of pthread_self into GetThreadForThis, GetThreadForThat? e.g. one is pthread_self, the other is GetCurrentThread/DuplicateHandle. That might come back. - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 12:08:09 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 16 Dec 2009, at 11:49, Jay K wrote:Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. Interesting, this is exactly the way Mach does signals (which is why we use the Mach suspend/resume primitives for Darwin/OSX). If that is how they work, then can't you use the suspend/resume primitives directly? There is only single parameter signal handlers. Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. That is what is particularly unfortunate. I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 11:40:56 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote:[again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Wed Dec 16 21:48:02 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 16 Dec 2009 12:48:02 -0800 (PST) Subject: [M3devel] Oops, forgot to ask Message-ID: <351872.44455.qm@web56806.mail.re3.yahoo.com> Hi Gang, 0 - CARDINALs are an integral type defined by the language spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, a change was made to CM3 to extend the language it recognizes beyond the original language spec (SPWM3), now CM3 understands a LONGINT. Was there a corresponding LONGCARD defined? Can is use all 64-bits, or is it restricted to 63, like the CARDINAL is only 31-bits. 1 - How does one write a WIDECHAR literal? Are WIDECHAR currently only 16-bits? If so they are limited to only the basic multilingual plane (BMP). Unicode characters are 20-bits, which is why encodings such as USC-32 exist. If a WIDECHAR is only 16-bits, are they encoded as UTF-16, which is a similar scheme to UTF-8? If they are currently only 16-bits, are there plans to expand it to fully support unicode character encodings? 2 - Recently there was discussion about creating a new type, that is halfway a REFANY, and halfway a value itself. I myself dislike unions, and fortran equivalences, and any other aliasing techniques, but if the compiler supports it, we should document it. What was it finally called? How does one declare an item of this type? How does one use it? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Wed Dec 16 22:31:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 16:31:00 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > Hi Gang, > > 0 - CARDINALs are an integral type defined by the language > spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > a change was made to CM3 to extend the language it recognizes > beyond the original language spec (SPWM3), now CM3 understands > a LONGINT. > > Was there a corresponding LONGCARD defined? No. But you can write: [0L..LAST(LONGINT)] just as CARDINAL=[0..LAST(INTEGER)] > Can is use all 64-bits, or is it restricted to 63, like > the CARDINAL is only 31-bits. 63 bits, since its underlying base type is LONGINT. > 1 - How does one write a WIDECHAR literal? Are WIDECHAR > currently only 16-bits? If so they are limited to only > the basic multilingual plane (BMP). Unicode characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are currently > only 16-bits, are there plans to expand it to fully support > unicode character encodings? I don't know... ? Probably should. > 2 - Recently there was discussion about creating a new type, > that is halfway a REFANY, and halfway a value itself. I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > we should document it. > > What was it finally called? > How does one declare an item of this type? > How does one use it? There is no new type like this. But, there is provision in the current implementation of the run-time system to ignore any reference value that has a low-bit set. The only way to use it is to LOOPHOLE values with low-bit set into REFANY. TYPECODE(r) for such tagged values returns what would be TYPECODE(REFANY) (but that expression is a compile-time error to write). So, anyone wanting to compare the typecode must use RT0.RefanyTypecode. The implications of all of this are that tagged REFANYs are implementation-dependent, and can only be used with the unsafe LOOPHOLE. In other words, it is not part of the language definition. And, the implementation may not support it in future... > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From dabenavidesd at yahoo.es Wed Dec 16 22:47:41 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Dec 2009 21:47:41 +0000 (GMT) Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <189565.77906.qm@web23601.mail.ird.yahoo.com> Hi Peter and all: I know think MAX(CARDINAL) should be of value 2^31 - 1 in 32 bits platforms.. There is no LONGCARD. If you want to perform unsigned arithmetic operations you can use WORD an you will have 2^32 values or 2^64 in 32 and 64 bits platform correspondent. Concerning INTEGER historically has been 32 bits in 32 bits word size platforms and (by now) 64 bits in 64 bits platforms. LONGINT is tought to be 64 bit in supported platforms (NT386 integrated backend doesn't have it yet). So that Another note about historical type changes I could add is that Math interface to C native library its function return types were once REAL but now are LONGREAL. You can convert LONGREAL to REAL values doing FLOAT(Math.Degree, REAL) for code expecting REAL values; I know WIDECHAR is an additional representation of TEXT in such a case you want to pop WIDECHAR values you will get it from Text interface, all supported platforms have it, I guess the intended use is related to interface native C types and besides the UTF-8 Java Virtual Machine standard internal codification (Modula-3 doesn't enforce that, so there could be an implementation with such encoding I think, said that, so far now, CM3 is not UTF-8 coded as I know) What I understood about having BRANDED REF is to allow C (calloc) capability of having REF values dynamically allocated in stack memory, allowing speed up in programs that use that (calloc C correspondent). I don't about how does affect type system tough, I mean following Modula-3 BRANDED OBJECT type objects have nominal type equivalence (different from default structural type equivalence) it should be the same for BRANDED REF I think thats all I know for know, hope it helps --- El mi?, 16/12/09, Peter Eiserloh escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Oops, forgot to ask > Para: "M3Devel" > Fecha: mi?rcoles, 16 de diciembre, 2009 15:48 > Hi Gang, > > 0 - CARDINALs are an integral type defined by the language > spec to be from 0 (zero) to MAXINT (not MAXCARD). > Recently, > a change was made to CM3 to extend the language it > recognizes > beyond the original language spec (SPWM3), now CM3 > understands > a LONGINT. > > Was there a corresponding LONGCARD defined? > Can is use all 64-bits, or is it restricted to 63, like > the CARDINAL is only 31-bits. > > > 1 - How does one write a WIDECHAR literal? Are > WIDECHAR > currently only 16-bits? If so they are limited to > only > the basic multilingual plane (BMP). Unicode > characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are > currently > only 16-bits, are there plans to expand it to fully support > > unicode character encodings? > > > 2 - Recently there was discussion about creating a new > type, > that is halfway a REFANY, and halfway a value itself. > I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > > we should document it. > > What was it finally called? > How does one declare an item of this type? > How does one use it? > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > > | > +--------------------------------------------------------+ > > > > From rodney_bates at lcwb.coop Wed Dec 16 23:56:55 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2009 16:56:55 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> Message-ID: <4B2965B7.6040304@lcwb.coop> Tony Hosking wrote: > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > >> Hi Gang, >> >> 0 - CARDINALs are an integral type defined by the language >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, >> a change was made to CM3 to extend the language it recognizes >> beyond the original language spec (SPWM3), now CM3 understands >> a LONGINT. >> >> Was there a corresponding LONGCARD defined? >> > > No. But you can write: > > [0L..LAST(LONGINT)] > > just as > > CARDINAL=[0..LAST(INTEGER)] > Actually, the line above was once true, long long ago, when dinosaurs roamed unfettered. CARDINAL was changed to be "just like" (but not equal to) [0..LAST(INTEGER)]. This would have been maybe early 1990s. It took me years to figure out what this actually meant, and more years to figure out why, but I believe I now know. CARDINAL is not an equal type to [0..LAST(INTEGER)], but otherwise has all the same properties. This makes the two mutually assignable, which is close enough to equal to not matter in most contexts. The exact consequences follow from other language rules. The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of machines with different values of LAST(INTEGER)), because the numeric value of LAST(INTEGER) is part of the expanded type. The one place this matters is if you use pickles to transfer data between machines of different word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash of the complete, expanded type definition) is different on the two machines, and values of or containing this type cannot be transferred. Exact type signature matches are used in pickles to find corresponding types when reading. But pickles handle different sized INTEGER values fine, expanding/shortening as needed. Being a leaf in a type definition, INTEGER is always the same type on any machine. So CARDINAL was changed to be its own unique type too, so it would be possible also to transfer CARDINAL values in pickles between different word sizes. So, we really should have a LONGCARD, parallel to CARDINAL. Note that this also affects network objects, which use pickles to transfer values of the objects. > > >> Can is use all 64-bits, or is it restricted to 63, like >> the CARDINAL is only 31-bits. >> > > 63 bits, since its underlying base type is LONGINT. > > > >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> >> > > > From hendrik at topoi.pooq.com Thu Dec 17 00:13:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Dec 2009 18:13:49 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <20091216231349.GB15089@topoi.pooq.com> On Wed, Dec 16, 2009 at 12:48:02PM -0800, Peter Eiserloh wrote: > > 2 - Recently there was discussion about creating a new type, > that is halfway a REFANY, and halfway a value itself. I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > we should document it. I too hate C unions and fortran equivalences. They cause program breakage, because they're violently insecure. But that's not that these are. These things are properly type-tagged, and if further it is impossible to get at their contents without checking the proper type-tag. -- hendrik From rodney_bates at lcwb.coop Thu Dec 17 00:35:29 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2009 17:35:29 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <4B296EC1.1080407@lcwb.coop> Peter Eiserloh wrote: > Hi Gang, > > > > 1 - How does one write a WIDECHAR literal? Are WIDECHAR > currently only 16-bits? If so they are limited to only > the basic multilingual plane (BMP). Put a 'W' or 'w' immediately before the opening single quote of a character literal, and it becomes a WIDECHAR literal. It has type WIDECHAR, allows characters with 16-bit codes, and also allows 16-bit octal and hex escapes. You can do the same with TEXT literals, but there is no such thing as "WIDETEXT". There is only one type TEXT and it can contain any characters in the 16-bit range. The internal representation has many options, dynamically chosen, and part or all of the value may be represented using only 8 bits per character, if the character values permit. Normally, this is all hidden. > Unicode characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are currently > only 16-bits, are there plans to expand it to fully support > unicode character encodings? > There have been some heated wars in this list over how to represent characters in the 16- and 20- bit ranges, with no consensus, that I saw. It is confused by the fact that you can easily put different representations into the same data type, without language changes. I tend to favor fixed-size representations for in-memory program variables, to preserve constant-time subscripted access. But the variable sized representations appear to allow certain common cases to be handled by unmodified source code, written originally for only 8-bit characters. > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From jay.krell at cornell.edu Thu Dec 17 01:52:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Dec 2009 00:52:06 +0000 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2965B7.6040304@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, <4B2965B7.6040304@lcwb.coop> Message-ID: "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. (Actually it would have been useful long ago.) I really think "long" is a dumb name.. There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. - Jay > Date: Wed, 16 Dec 2009 16:56:55 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Oops, forgot to ask > > Tony Hosking wrote: > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > >> Hi Gang, > >> > >> 0 - CARDINALs are an integral type defined by the language > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > >> a change was made to CM3 to extend the language it recognizes > >> beyond the original language spec (SPWM3), now CM3 understands > >> a LONGINT. > >> > >> Was there a corresponding LONGCARD defined? > >> > > > > No. But you can write: > > > > [0L..LAST(LONGINT)] > > > > just as > > > > CARDINAL=[0..LAST(INTEGER)] > > > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in > pickles > between different word sizes. > > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > >> the CARDINAL is only 31-bits. > >> > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > >> > >> > >> > >> +--------------------------------------------------------+ > >> | Peter P. Eiserloh | > >> +--------------------------------------------------------+ > >> > >> > >> > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 17 02:06:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 20:06:52 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2965B7.6040304@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> Message-ID: <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> This does not make sense: Here is the compiler's definition of the builtin CARDINAL type: MODULE Card; IMPORT SubrangeType, Target, TInt, Tipe, Int; PROCEDURE Initialize () = BEGIN T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); Tipe.Define ("CARDINAL", T, TRUE); END Initialize; BEGIN END Card. Notice that it is a subrange type [0..LAST(INTEGER)]. 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 16 Dec 2009, at 17:56, Rodney M. Bates wrote: > Tony Hosking wrote: >> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: >> >> >>> Hi Gang, >>> >>> 0 - CARDINALs are an integral type defined by the language >>> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, >>> a change was made to CM3 to extend the language it recognizes >>> beyond the original language spec (SPWM3), now CM3 understands >>> a LONGINT. >>> Was there a corresponding LONGCARD defined? >>> >> >> No. But you can write: >> >> [0L..LAST(LONGINT)] >> >> just as >> >> CARDINAL=[0..LAST(INTEGER)] >> > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in pickles > between different word sizes. > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > >> >> >>> Can is use all 64-bits, or is it restricted to 63, like >>> the CARDINAL is only 31-bits. >>> >> >> 63 bits, since its underlying base type is LONGINT. >> >> >> >>> >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> >>> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 17 02:10:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 20:10:14 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, <4B2965B7.6040304@lcwb.coop> Message-ID: On 16 Dec 2009, at 19:52, Jay K wrote: > "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? > > > See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. > (Actually it would have been useful long ago.) LONGINT could be 128 bits for all its definition cares. It is just something usually (not always) bigger than an INTEGER. > I really think "long" is a dumb name.. > There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. Now these are dumb names because they wire in the size of the value. In Modula-3 INTEGER is a natural (i.e., word-size) value. > > > - Jay > > > > Date: Wed, 16 Dec 2009 16:56:55 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Oops, forgot to ask > > > > Tony Hosking wrote: > > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > > > > >> Hi Gang, > > >> > > >> 0 - CARDINALs are an integral type defined by the language > > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > > >> a change was made to CM3 to extend the language it recognizes > > >> beyond the original language spec (SPWM3), now CM3 understands > > >> a LONGINT. > > >> > > >> Was there a corresponding LONGCARD defined? > > >> > > > > > > No. But you can write: > > > > > > [0L..LAST(LONGINT)] > > > > > > just as > > > > > > CARDINAL=[0..LAST(INTEGER)] > > > > > Actually, the line above was once true, long long ago, when dinosaurs > > roamed unfettered. CARDINAL was changed to be "just like" > > (but not equal to) [0..LAST(INTEGER)]. This would have been > > maybe early 1990s. > > > > It took me years to figure out what this actually meant, and more > > years to figure out why, but I believe I now know. CARDINAL is not an > > equal type to [0..LAST(INTEGER)], but otherwise has all the same > > properties. This makes the two mutually assignable, which is close > > enough to equal to not matter in most contexts. The exact consequences > > follow from other language rules. > > > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > > machines with different values of LAST(INTEGER)), because the numeric > > value of LAST(INTEGER) is part of the expanded type. The one place this > > matters is if you use pickles to transfer data between machines of different > > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > > of the complete, expanded type definition) is different on the two machines, > > and values of or containing this type cannot be transferred. Exact type > > signature matches are used in pickles to find corresponding types when > > reading. > > > > But pickles handle different sized INTEGER values fine, expanding/shortening > > as needed. Being a leaf in a type definition, INTEGER is always the same > > type on any machine. So CARDINAL was changed to be its own unique > > type too, so it would be possible also to transfer CARDINAL values in > > pickles > > between different word sizes. > > > > So, we really should have a LONGCARD, parallel to CARDINAL. > > > > Note that this also affects network objects, which use pickles to transfer > > values of the objects. > > > > > > > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > > >> the CARDINAL is only 31-bits. > > >> > > > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > > > > > >> > > >> > > >> > > >> +--------------------------------------------------------+ > > >> | Peter P. Eiserloh | > > >> +--------------------------------------------------------+ > > >> > > >> > > >> > > >> > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 17 02:55:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Dec 2009 01:55:15 +0000 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, , <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, , <4B2965B7.6040304@lcwb.coop>, , Message-ID: These would be "base" types and people would have to pick and chose their own typedefs to suit their needs. Imho the idea of a "natural" size is a nice theory but it turns out that "we" (in the larger software world) are stuck with the exact sizes as they happen to have been for a while. C int will always be 32 bits. Growing it will break too much code. Even if processors get natural 128 bit integers, they will still always have to deal efficiently with 32 bit integers because 32 bit integers won't go away. Ditto now 64bit integers. As well natural is great for a local variable, but as soon as you start allocating things in large numbers, you start wanting the size to not be much larger than is needed and you consider the range you'll actually need..sometimes it is obviously small, sometimes not. If it isn't obviously small then you can err toward a larger type like or int or size_t. If it is obviously a small range and allocated in large number then you'll more seriously consider UINT8 or UINT16. If the range is unavoidably huge then you'll consider floating point or a multiple precision option. Granted, Modula-3 does have "BITS FOR" and subranges. I'm not used to having those. So maybe these types aren't needed since you can build them. The compiler does certainly have these exact types internally though. And the processors generally all have instructions that operate on them (with varying efficiency though). If you consider C, people often have int, long, long long. This is as I said dumb because what will 128 integers be called, "long long long"? "byte", "short", "long" these are just funny informal names. A more mechanical system is INT8, INT16, INT32 or PTRDIFF_T. I grant that there is base integer type with the size of a pointer, that doesn't have the exact number of bits encoded. Perhaps Modula-3 doesn't have such a bad legacy codebase? Perhaps growing INTEGER to 64bits didn't break anything and growing it to 128 won't either? Perhaps persistance is generally pickles and they deal better with this stuff, and not like direct blitting? Anyway, - Jay From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 20:10:14 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Oops, forgot to ask On 16 Dec 2009, at 19:52, Jay K wrote: "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. (Actually it would have been useful long ago.) LONGINT could be 128 bits for all its definition cares. It is just something usually (not always) bigger than an INTEGER. I really think "long" is a dumb name.. There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. Now these are dumb names because they wire in the size of the value. In Modula-3 INTEGER is a natural (i.e., word-size) value. - Jay > Date: Wed, 16 Dec 2009 16:56:55 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Oops, forgot to ask > > Tony Hosking wrote: > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > >> Hi Gang, > >> > >> 0 - CARDINALs are an integral type defined by the language > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > >> a change was made to CM3 to extend the language it recognizes > >> beyond the original language spec (SPWM3), now CM3 understands > >> a LONGINT. > >> > >> Was there a corresponding LONGCARD defined? > >> > > > > No. But you can write: > > > > [0L..LAST(LONGINT)] > > > > just as > > > > CARDINAL=[0..LAST(INTEGER)] > > > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in > pickles > between different word sizes. > > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > >> the CARDINAL is only 31-bits. > >> > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > >> > >> > >> > >> +--------------------------------------------------------+ > >> | Peter P. Eiserloh | > >> +--------------------------------------------------------+ > >> > >> > >> > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 06:01:41 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 6 Dec 2009 21:01:41 -0800 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> References: , <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> Message-ID: <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> Clarfication, I meant traced heap allocation, the copying of timezone. Could copy to local array then enable switching then alloc/copy. But what I did should be ok. - Jay (phone) On Dec 6, 2009, at 11:14 AM, Tony Hosking wrote: > On 6 Dec 2009, at 09:29, Jay K wrote: > >> I was thinking of that -- DisableSwitching / EnableSwitching -- but >> can the heap allocation happen while >> switching is disabled? > > Yes, it sure can. DisableSwitching/EnableSwitching is exactly what > is needed whenever you are dealing with libraries that are not > thread safe with the user-level thread-switching. > >> I came up with something a bit hacky but maybe ok. >> >> - Jay >> >> >> Subject: Re: [M3devel] DateBsd.m3 lock usually not needed >> From: hosking at cs.purdue.edu >> Date: Sun, 6 Dec 2009 09:25:58 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> That's what SchedulerPosix (badly named but linked to the old user- >> threads naming) is for.... >> >> 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 6 Dec 2009, at 06:48, Jay K wrote: >> >> It'd be nice if DateBsd.m3 only used a lock with user threads and >> not with pthreads/ntthreads. >> >> - Jay >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 17 03:24:36 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Dec 2009 21:24:36 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <4B2965B7.6040304@lcwb.coop> Message-ID: <20091217022436.GC15937@topoi.pooq.com> On Thu, Dec 17, 2009 at 12:52:06AM +0000, Jay K wrote: > > I really think "long" is a dumb name.. > > There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, > UINT64, and unsigned and signed integers the same size of a pointer, > possibly called INT and UINT, or size_t and ptrdiff_t.. Well, in Modula 3, it probably should something like SIZE and PRTDIFF. -- hendrik From hosking at cs.purdue.edu Thu Dec 17 04:41:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 22:41:29 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> References: , <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> Message-ID: <0E815D43-FD27-4304-874D-928D96317389@cs.purdue.edu> Yes, heap allocation can happen while switching is disabled. On 7 Dec 2009, at 00:01, jay.krell at cornell.edu wrote: > Clarfication, I meant traced heap allocation, the copying of timezone. Could copy to local array then enable switching then alloc/copy. But what I did should be ok. > > - Jay (phone) > > On Dec 6, 2009, at 11:14 AM, Tony Hosking wrote: > >> On 6 Dec 2009, at 09:29, Jay K wrote: >> >>> I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while >>> switching is disabled? >> >> Yes, it sure can. DisableSwitching/EnableSwitching is exactly what is needed whenever you are dealing with libraries that are not thread safe with the user-level thread-switching. >> >>> I came up with something a bit hacky but maybe ok. >>> >>> - Jay >>> >>> >>> Subject: Re: [M3devel] DateBsd.m3 lock usually not needed >>> From: hosking at cs.purdue.edu >>> Date: Sun, 6 Dec 2009 09:25:58 -0500 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... >>> >>> 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 6 Dec 2009, at 06:48, Jay K wrote: >>> >>> It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. >>> >>> - Jay >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 17 16:08:41 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 09:08:41 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> Message-ID: <4B2A4979.7020401@lcwb.coop> Tony Hosking wrote: > This does not make sense: > > Here is the compiler's definition of the builtin CARDINAL type: > > MODULE Card; > > IMPORT SubrangeType, Target, TInt, Tipe, Int; > > PROCEDURE Initialize () = > BEGIN > T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); CARDINAL is builtin -----------------------------------------------^ > Tipe.Define ("CARDINAL", T, TRUE); > END Initialize; > > BEGIN > END Card. > > > Notice that it is a subrange type [0..LAST(INTEGER)]. > > 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 > And from MODULE SubrangeType: .... PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = VAR b: P := t; BEGIN Seal (a); Seal (b); RETURN (a.builtin = b.builtin) ^ --- builtin property must be the same for type equality AND TInt.EQ (a.min, b.min) AND TInt.EQ (a.max, b.max) AND Type.IsEqual (a.baseType, b.baseType, x); END EqualChk; ... PROCEDURE Parse (): Type.T = TYPE TK = Token.T; VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); Programmer-defined subrange is not builtin -- ^ BEGIN Match (TK.tLBRACKET); p.minE := Expr.Parse (); Match (TK.tDOTDOT); p.maxE := Expr.Parse (); Match (TK.tRBRACKET); RETURN p; END Parse; This program: MODULE Card EXPORTS Main ; TYPE C = CARDINAL ; TYPE D = [ 0 .. LAST ( INTEGER ) ] ; PROCEDURE DP ( VAR DPF : D ) = BEGIN DPF := 0 END DP ; PROCEDURE CP ( VAR CPF : C ) = BEGIN CPF := 0 END CP ; PROCEDURE Try ( ) = VAR CV : C ; VAR DV : D ; BEGIN CP ( CV ) ; CP ( DV ) <--- line 20 ; DP ( CV ) ; DP ( DV ) END Try ; BEGIN Try ( ) END Card . Gives these errors: rodney at allegheny:~/proj/m3/exp/card/src$ cm3 --- building in ../AMD64_LINUX --- new source -> compiling Card.m3 "../src/Card.m3", line 20: incompatible types (CPF) "../src/Card.m3", line 21: incompatible types (DPF) 2 errors encountered compilation failed => not building program "prog" Fatal Error: package build failed From hosking at cs.purdue.edu Thu Dec 17 17:12:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Dec 2009 11:12:26 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2A4979.7020401@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> <4B2A4979.7020401@lcwb.coop> Message-ID: <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> Aha! Thanks Rodney. Do we have any use-cases for LONGCARD? On 17 Dec 2009, at 10:08, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> This does not make sense: >> Here is the compiler's definition of the builtin CARDINAL type: >> MODULE Card; >> IMPORT SubrangeType, Target, TInt, Tipe, Int; >> PROCEDURE Initialize () = >> BEGIN >> T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); > > CARDINAL is builtin -----------------------------------------------^ > >> Tipe.Define ("CARDINAL", T, TRUE); >> END Initialize; >> BEGIN >> END Card. >> Notice that it is a subrange type [0..LAST(INTEGER)]. >> 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 > > And from MODULE SubrangeType: > > .... > > PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = > VAR b: P := t; > BEGIN > Seal (a); Seal (b); > RETURN (a.builtin = b.builtin) > > ^ --- builtin property must be the same for type equality > > AND TInt.EQ (a.min, b.min) > AND TInt.EQ (a.max, b.max) > AND Type.IsEqual (a.baseType, b.baseType, x); > END EqualChk; > > ... > > PROCEDURE Parse (): Type.T = > TYPE TK = Token.T; > VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); > > Programmer-defined subrange is not builtin -- ^ > > BEGIN > Match (TK.tLBRACKET); > p.minE := Expr.Parse (); > Match (TK.tDOTDOT); > p.maxE := Expr.Parse (); > Match (TK.tRBRACKET); > RETURN p; > END Parse; > > This program: > > MODULE Card EXPORTS Main > > ; TYPE C = CARDINAL > ; TYPE D = [ 0 .. LAST ( INTEGER ) ] > > ; PROCEDURE DP ( VAR DPF : D ) > = BEGIN > DPF := 0 > END DP > ; PROCEDURE CP ( VAR CPF : C ) > = BEGIN > CPF := 0 > END CP > > ; PROCEDURE Try ( ) > = VAR CV : C > ; VAR DV : D > ; BEGIN > CP ( CV ) > ; CP ( DV ) <--- line 20 > ; DP ( CV ) > ; DP ( DV ) > END Try > > ; BEGIN > Try ( ) > END Card -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Thu Dec 17 17:18:32 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 17 Dec 2009 08:18:32 -0800 (PST) Subject: [M3devel] INTEGER vice INT32 Message-ID: <213164.34773.qm@web56804.mail.re3.yahoo.com> Hi Tony, Both Jay, and yourself have valid points. One can classify the two kinds of types, as implicit, and explicit. More specifically, INTEGER is implicit, and is useful for in-memory representation. This was especially important when machine registers were very different between machines. Very few remember the days of 18-bit words, with 9-bit bytes (thank you!). An implicit type is very useful, when you are not worried about external representation and all one needs is the logical behavior of the type, independent of the particular machine on which one may currently be. Explicit types are much more useful, if not imperative, when defining data types for external storage (in files, or network protocols). For binary file IO many people take a naive approach, and simply overlay a data structure onto the file stream. This ignores the potential difference in sizes of implicit types, and their endianess. A more careful method of doing binary files, is to distinguish the external from the internal representation, and have procedures to do the IO a field at a time. See binIO. Back in the late 1980's, and early 1990s, I had an Amiga computer, and had two different "C" compilers: Aztec, C and SAS/C. The Aztec compiler int was 16-bits, whereas the SAS/C int was 32 bits. As you can imagine this caused all sorts of havoc. The Amiga system includes were rewritten with somewhat more explicit types. These were macros such as ULONG, SLONG, USHORT, SSHORT, UBYTE, and SBYTE. This illustrates the importance of explicit types. Both implicit and explicit types have their place. Peter Date: Wed, 16 Dec 2009 20:10:14 -0500 From: Tony Hosking Subject: Re: [M3devel] Oops, forgot to ask To: Jay K Cc: m3devel Message-ID: Content-Type: text/plain; charset="us-ascii" >On 16 Dec 2009, at 19:52, Jay K wrote: > >> "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 >bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? >> >> >> See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. >> (Actually it would have been useful long ago.) > >LONGINT could be 128 bits for all its definition cares. It is just >something usually (not always) bigger than an INTEGER. > >> I really think "long" is a dumb name.. >> There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, >UINT64, and unsigned and signed integers the same size of a pointer, >possibly called INT and UINT, or size_t and ptrdiff_t.. > >Now these are dumb names because they wire in the size of the value. > >In Modula-3 INTEGER is a natural (i.e., word-size) value. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Thu Dec 17 17:30:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Dec 2009 11:30:47 -0500 Subject: [M3devel] INTEGER vice INT32 In-Reply-To: <213164.34773.qm@web56804.mail.re3.yahoo.com> References: <213164.34773.qm@web56804.mail.re3.yahoo.com> Message-ID: <92DD86C0-2379-49D0-87B6-DABF67AF3D45@cs.purdue.edu> But we *do* have explicit types in Modula-3. Subranges and BITS FOR let us pretty much do everything we want (the current implementation restrictions are in using underlying in-memory representations for subranges that round to the nearest byte size). 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 17 Dec 2009, at 11:18, Peter Eiserloh wrote: > Hi Tony, > > Both Jay, and yourself have valid points. > > One can classify the two kinds of types, as implicit, and > explicit. > > More specifically, INTEGER is implicit, and is useful for > in-memory representation. This was especially important > when machine registers were very different between machines. > Very few remember the days of 18-bit words, with 9-bit > bytes (thank you!). An implicit type is very useful, > when you are not worried about external representation > and all one needs is the logical behavior of the type, > independent of the particular machine on which one may > currently be. > > Explicit types are much more useful, if not imperative, > when defining data types for external storage (in files, > or network protocols). > > For binary file IO many people take a naive approach, and > simply overlay a data structure onto the file stream. > This ignores the potential difference in sizes of implicit > types, and their endianess. A more careful method of > doing binary files, is to distinguish the external from > the internal representation, and have procedures to do > the IO a field at a time. See binIO. > > Back in the late 1980's, and early 1990s, I had an Amiga > computer, and had two different "C" compilers: Aztec, C > and SAS/C. The Aztec compiler int was 16-bits, whereas > the SAS/C int was 32 bits. As you can imagine this caused > all sorts of havoc. The Amiga system includes were > rewritten with somewhat more explicit types. These were > macros such as ULONG, SLONG, USHORT, SSHORT, UBYTE, and > SBYTE. > > This illustrates the importance of explicit types. > Both implicit and explicit types have their place. > > > Peter > > > > Date: Wed, 16 Dec 2009 20:10:14 -0500 > From: Tony Hosking > Subject: Re: [M3devel] Oops, forgot to ask > To: Jay K > Cc: m3devel > Message-ID: > Content-Type: text/plain; charset="us-ascii" > >> On 16 Dec 2009, at 19:52, Jay K wrote: >> >>> "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 >> bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? >>> >>> >>> See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. >>> (Actually it would have been useful long ago.) >> >> LONGINT could be 128 bits for all its definition cares. It is just >> something usually (not always) bigger than an INTEGER. >> >>> I really think "long" is a dumb name.. >>> There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, >> UINT64, and unsigned and signed integers the same size of a pointer, >> possibly called INT and UINT, or size_t and ptrdiff_t.. >> >> Now these are dumb names because they wire in the size of the value. >> >> In Modula-3 INTEGER is a natural (i.e., word-size) value. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Thu Dec 17 18:46:31 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 17 Dec 2009 09:46:31 -0800 (PST) Subject: [M3devel] Widechar literals [Was Re: Oops, forgot to ask (Rodney M. Bates) Message-ID: <220296.21268.qm@web56805.mail.re3.yahoo.com> Thank you Rodney. So, if I wanted to represent GREEK SMALL LETTER ALPHA: CONST GreekSmallAlpha = W'03B1'; (* WIDECHAR *) I may not have understood properly. This is not explained in http://www.opencm3.net/doc/reference/texts.html There should be a way of specifying that this is a hex value. Octal values are of course introduced with a backslash followed by a three octal digits. I would have liked to see something like a backslash followed by an x or X and four hexadecimal digits to give the 16-bit value. As in W'\x03B1'. If we were to ever get full unicode support (20-bits) we may need an escape for it. The unicode standard lists code points as in "U+003B1", so a similar escape may look like W'\u003B1'. Next question: are the hexadecimal digits case insensitive? Peter >Date: Wed, 16 Dec 2009 17:35:29 -0600 >From: "Rodney M. Bates" >Subject: Re: [M3devel] Oops, forgot to ask >To: M3Devel >Message-ID: <4B296EC1.1080407 at lcwb.coop> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Peter Eiserloh wrote: >> Hi Gang, >> >> >> >> 1 - How does one write a WIDECHAR literal? Are WIDECHAR >> currently only 16-bits? If so they are limited to only >> the basic multilingual plane (BMP). > >Put a 'W' or 'w' immediately before the opening single >quote of a character literal, and it becomes a WIDECHAR >literal. It has type WIDECHAR, allows characters with >16-bit codes, and also allows 16-bit octal and hex escapes. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From rodney_bates at lcwb.coop Thu Dec 17 20:30:39 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 13:30:39 -0600 Subject: [M3devel] Widechar literals [Was Re: Oops, forgot to ask (Rodney M. Bates) In-Reply-To: <220296.21268.qm@web56805.mail.re3.yahoo.com> References: <220296.21268.qm@web56805.mail.re3.yahoo.com> Message-ID: <4B2A86DF.3070101@lcwb.coop> If the literal (CHAR or TEXT) is not wide, you can have a backslash followed by exactly 3 octal digits as an escape. Or, backslash, followed by 'x' or 'X', followed by exactly two hex digits. For wide literals (WIDECHAR or TEXT), the number of octal digits is exactly 6 and for hex, exactly four. The hex digits are not case sensitive. The same is true for hex digits in numeric literals too. Peter Eiserloh wrote: > Thank you Rodney. > > So, if I wanted to represent GREEK SMALL LETTER ALPHA: > > CONST > GreekSmallAlpha = W'03B1'; (* WIDECHAR *) > > I may not have understood properly. > > This is not explained in > http://www.opencm3.net/doc/reference/texts.html ^ --- I've put this on my list to fix. > > There should be a way of specifying that this is a > hex value. Octal values are of course introduced > with a backslash followed by a three octal digits. > I would have liked to see something like a backslash > followed by an x or X and four hexadecimal digits > to give the 16-bit value. As in W'\x03B1'. > > If we were to ever get full unicode support (20-bits) > we may need an escape for it. The unicode standard > lists code points as in "U+003B1", so a similar escape > may look like W'\u003B1'. > > > Next question: are the hexadecimal digits case insensitive? > > > > Peter > > >> Date: Wed, 16 Dec 2009 17:35:29 -0600 >> From: "Rodney M. Bates" >> Subject: Re: [M3devel] Oops, forgot to ask >> To: M3Devel >> Message-ID: <4B296EC1.1080407 at lcwb.coop> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Peter Eiserloh wrote: >>> Hi Gang, >>> >>> >>> >>> 1 - How does one write a WIDECHAR literal? Are WIDECHAR >>> currently only 16-bits? If so they are limited to only >>> the basic multilingual plane (BMP). >> Put a 'W' or 'w' immediately before the opening single >> quote of a character literal, and it becomes a WIDECHAR >> literal. It has type WIDECHAR, allows characters with >> 16-bit codes, and also allows 16-bit octal and hex escapes. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > From rodney_bates at lcwb.coop Thu Dec 17 22:29:00 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 15:29:00 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> <4B2A4979.7020401@lcwb.coop> <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> Message-ID: <4B2AA29C.5050708@lcwb.coop> The only one I know of is if you want to a pickle or network object with a long field that is nonnegative, but you want its size to be converted between different native word sizes when reading the pickles. Tony Hosking wrote: > Aha! Thanks Rodney. Do we have any use-cases for LONGCARD? > > On 17 Dec 2009, at 10:08, Rodney M. Bates wrote: > >> >> >> Tony Hosking wrote: >>> This does not make sense: >>> Here is the compiler's definition of the builtin CARDINAL type: >>> MODULE Card; >>> IMPORT SubrangeType, Target, TInt, Tipe, Int; >>> PROCEDURE Initialize () = >>> BEGIN >>> T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); >> >> CARDINAL is builtin -----------------------------------------------^ >> >>> Tipe.Define ("CARDINAL", T, TRUE); >>> END Initialize; >>> BEGIN >>> END Card. >>> Notice that it is a subrange type [0..LAST(INTEGER)]. >>> 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 >> >> And from MODULE SubrangeType: >> >> .... >> >> PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = >> VAR b: P := t; >> BEGIN >> Seal (a); Seal (b); >> RETURN (a.builtin = b.builtin) >> >> ^ --- builtin property must be the same for type equality >> >> AND TInt.EQ (a.min, b.min) >> AND TInt.EQ (a.max, b.max) >> AND Type.IsEqual (a.baseType, b.baseType, x); >> END EqualChk; >> >> ... >> >> PROCEDURE Parse (): Type.T = >> TYPE TK = Token.T; >> VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); >> >> Programmer-defined subrange is not builtin -- ^ >> >> BEGIN >> Match (TK.tLBRACKET); >> p.minE := Expr.Parse (); >> Match (TK.tDOTDOT); >> p.maxE := Expr.Parse (); >> Match (TK.tRBRACKET); >> RETURN p; >> END Parse; >> >> This program: >> >> MODULE Card EXPORTS Main >> >> ; TYPE C = CARDINAL >> ; TYPE D = [ 0 .. LAST ( INTEGER ) ] >> >> ; PROCEDURE DP ( VAR DPF : D ) >> = BEGIN >> DPF := 0 >> END DP >> ; PROCEDURE CP ( VAR CPF : C ) >> = BEGIN >> CPF := 0 >> END CP >> >> ; PROCEDURE Try ( ) >> = VAR CV : C >> ; VAR DV : D >> ; BEGIN >> CP ( CV ) >> ; CP ( DV ) <--- line 20 >> ; DP ( CV ) >> ; DP ( DV ) >> END Try >> >> ; BEGIN >> Try ( ) >> END Card > From jay.krell at cornell.edu Fri Dec 18 19:04:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 18:04:27 +0000 Subject: [M3devel] cas/casp? Message-ID: Tony is this right? conceptually: result := CAS(VAR destination, compare, exchange) old := destination if old := compare then destination = exchange return old bool result := CASP(VAR destination, compare, exchange) P for predicate aka returning bool old := destination if old = compare then destination := exchange return true return false I'm pretty sure it is. I'll have this for 16 bit and 32 bit values shortly, for now requiring a recent Microsoft compiler and it generates function calls. But inlining should be easy enough. And then 8bit and 64bit. Also this will probably not work on 386 or 486 but require Pentium or somesuch. I don't know when various instructions were introduced but I know 386 is much poorer here than modern processors. I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t and not e.g. floating point. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 18 19:23:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 18:23:59 +0000 Subject: [M3devel] cas/casp? In-Reply-To: References: Message-ID: Nevermind. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Fri, 18 Dec 2009 18:04:27 +0000 Subject: [M3devel] cas/casp? Tony is this right? conceptually: result := CAS(VAR destination, compare, exchange) old := destination if old := compare then destination = exchange return old bool result := CASP(VAR destination, compare, exchange) P for predicate aka returning bool old := destination if old = compare then destination := exchange return true return false I'm pretty sure it is. I'll have this for 16 bit and 32 bit values shortly, for now requiring a recent Microsoft compiler and it generates function calls. But inlining should be easy enough. And then 8bit and 64bit. Also this will probably not work on 386 or 486 but require Pentium or somesuch. I don't know when various instructions were introduced but I know 386 is much poorer here than modern processors. I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t and not e.g. floating point. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 19:32:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 13:32:57 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: Message-ID: <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. GENERIC INTERFACE Atomic(Rep); IMPORT RTMachine; TYPE T = Rep.T; PROCEDURE MemoryFence(); (* Guarantees explicit memory ordering for otherwise unordered atomics, and for other memory references wrt atomics. Not useful for ordering ordinary memory references, since those may not race and, if they don't race, always appear to be ordered. *) PROCEDURE CompilerFence(); (* Ensures that prior memory operations appear in the instruction stream before subsequent ones, i.e. the compiler is not allowed to reorder around this. This really has only implementation-defined semantics, but it seems to be useful in ensuring ordering with respect to signal handlers and the like. *) PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) PROCEDURE StoreRelease(VAR var: T; val: T); PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) PROCEDURE LoadAcquire(READONLY var: T): T; TYPE Order = { Raw, Acquire, Release, Ordered }; (* "Raw" ==> This operation is unordered, and may become visible to other threads in an order that is constrained only by ordering constraints on other operations. "Release" ==> All prior memory operations (including ordinary assignments) become visible to a an acquire operation on the same object that sees the resulting value. "Acquire" ==> See above. "Ordered" ==> Both acquire and release ordering properties.*) CONST HasCas = RTMachine.HasCas; CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; (* Most architectures provide a way to return the old value. On those that do not, it can be emulated with an additional load, at the expense of wait-freedom or spurious failure. *) CONST HasWeakCas = RTMachine.HasWeakCas; PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; (* Similar to "Cas", but may fail spuriously, and must be wait-free, if provided. *) CONST HasFetchAdd = RTMachine.HasFetchAdd; PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; CONST HasFetchOr = RTMachine.HasFetchOr; PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; CONST HasFetchAnd = RTMachine.HasFetchAnd; PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; END Atomic. On 18 Dec 2009, at 13:04, Jay K wrote: > Tony is this right? > > > conceptually: > > > result := CAS(VAR destination, compare, exchange) > > > old := destination > if old := compare then > destination = exchange > return old > > > bool result := CASP(VAR destination, compare, exchange) > P for predicate aka returning bool > > > old := destination > if old = compare then > destination := exchange > return true > return false > > > I'm pretty sure it is. > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > a recent Microsoft compiler and it generates function calls. > But inlining should be easy enough. > And then 8bit and 64bit. > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > I don't know when various instructions were introduced but I know > 386 is much poorer here than modern processors. > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > and not e.g. floating point. > > > - Jay From jay.krell at cornell.edu Fri Dec 18 20:06:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 19:06:06 +0000 Subject: [M3devel] cas/casp? In-Reply-To: <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Message-ID: oh. I already got it working. ok. Atomic confuses me in a few ways. I find it terribly confusing on Windows that there are separate compiler and memory fences. I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. It makes no sense to me to allow the processor or compiler to reorder but not both. What is weak cas? Is that loadlocked/storecondition and the caller can loop? Um. There is the Windows terminology InterlockedWhatever. There is the gccc builtins. Can we "sound" close to one of them? Or is this based on some other widely known system? And we don't care about older x86 processors like 386?486 I assume? There seem to have been at least two leaps in functionality here. Old Win32 operating systems provide very few interlocked functions. They provide increment and decrement, that only return <0, 0, >0 of the new value. And Exchange. (This is based on the Visual C++ 2.0 winbase.h) All just on 32bit values. Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 13:32:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cas/casp? > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > GENERIC INTERFACE Atomic(Rep); > > IMPORT RTMachine; > > TYPE T = Rep.T; > > PROCEDURE MemoryFence(); > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > for other memory references wrt atomics. Not useful for ordering > ordinary memory references, since those may not race and, if they don't > race, always appear to be ordered. *) > > PROCEDURE CompilerFence(); > (* Ensures that prior memory operations appear in the instruction stream > before subsequent ones, i.e. the compiler is not allowed to reorder > around this. This really has only implementation-defined semantics, but > it seems to be useful in ensuring ordering with respect to signal > handlers and the like. *) > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > PROCEDURE StoreRelease(VAR var: T; val: T); > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > PROCEDURE LoadAcquire(READONLY var: T): T; > > TYPE Order = { Raw, Acquire, Release, Ordered }; > (* "Raw" ==> This operation is unordered, and may become visible to other > threads in an order that is constrained only by ordering constraints > on other operations. > > "Release" ==> All prior memory operations (including ordinary > assignments) become visible to a an acquire operation on the same > object that sees the resulting value. > > "Acquire" ==> See above. > > "Ordered" ==> Both acquire and release ordering properties.*) > > CONST HasCas = RTMachine.HasCas; > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > (* Most architectures provide a way to return the old value. On those that > do not, it can be emulated with an additional load, at the expense of > wait-freedom or spurious failure. *) > > CONST HasWeakCas = RTMachine.HasWeakCas; > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > provided. *) > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > CONST HasFetchOr = RTMachine.HasFetchOr; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > END Atomic. > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > Tony is this right? > > > > > > conceptually: > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > old := destination > > if old := compare then > > destination = exchange > > return old > > > > > > bool result := CASP(VAR destination, compare, exchange) > > P for predicate aka returning bool > > > > > > old := destination > > if old = compare then > > destination := exchange > > return true > > return false > > > > > > I'm pretty sure it is. > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > a recent Microsoft compiler and it generates function calls. > > But inlining should be easy enough. > > And then 8bit and 64bit. > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > I don't know when various instructions were introduced but I know > > 386 is much poorer here than modern processors. > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > and not e.g. floating point. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 20:12:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 14:12:44 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Message-ID: <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> On 18 Dec 2009, at 14:06, Jay K wrote: > oh. I already got it working. ok. > > Atomic confuses me in a few ways. > > I find it terribly confusing on Windows that there are separate compiler and memory fences. > I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. > It makes no sense to me to allow the processor or compiler to reorder but not both. > > > What is weak cas? It's a CAS that can fail spuriously. i.e., even if the old value was ==. > Is that loadlocked/storecondition and the caller can loop? > > > Um. There is the Windows terminology InterlockedWhatever. > There is the gccc builtins. > Can we "sound" close to one of them? > Or is this based on some other widely known system? The Atomic interface I posted is based on a proposal for the C++ standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html > And we don't care about older x86 processors like 386?486 I assume? > There seem to have been at least two leaps in functionality here. > Old Win32 operating systems provide very few interlocked functions. > They provide increment and decrement, that only return <0, 0, >0 of the new value. > And Exchange. (This is based on the Visual C++ 2.0 winbase.h) > All just on 32bit values. > > Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. > > And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. > > And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. > >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 18 Dec 2009 13:32:57 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] cas/casp? > > > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > > > GENERIC INTERFACE Atomic(Rep); > > > > IMPORT RTMachine; > > > > TYPE T = Rep.T; > > > > PROCEDURE MemoryFence(); > > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > > for other memory references wrt atomics. Not useful for ordering > > ordinary memory references, since those may not race and, if they don't > > race, always appear to be ordered. *) > > > > PROCEDURE CompilerFence(); > > (* Ensures that prior memory operations appear in the instruction stream > > before subsequent ones, i.e. the compiler is not allowed to reorder > > around this. This really has only implementation-defined semantics, but > > it seems to be useful in ensuring ordering with respect to signal > > handlers and the like. *) > > > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > > PROCEDURE StoreRelease(VAR var: T; val: T); > > > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > > PROCEDURE LoadAcquire(READONLY var: T): T; > > > > TYPE Order = { Raw, Acquire, Release, Ordered }; > > (* "Raw" ==> This operation is unordered, and may become visible to other > > threads in an order that is constrained only by ordering constraints > > on other operations. > > > > "Release" ==> All prior memory operations (including ordinary > > assignments) become visible to a an acquire operation on the same > > object that sees the resulting value. > > > > "Acquire" ==> See above. > > > > "Ordered" ==> Both acquire and release ordering properties.*) > > > > CONST HasCas = RTMachine.HasCas; > > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > > (* Most architectures provide a way to return the old value. On those that > > do not, it can be emulated with an additional load, at the expense of > > wait-freedom or spurious failure. *) > > > > CONST HasWeakCas = RTMachine.HasWeakCas; > > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > > provided. *) > > > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > > > CONST HasFetchOr = RTMachine.HasFetchOr; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > END Atomic. > > > > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > > > Tony is this right? > > > > > > > > > conceptually: > > > > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > > > > old := destination > > > if old := compare then > > > destination = exchange > > > return old > > > > > > > > > bool result := CASP(VAR destination, compare, exchange) > > > P for predicate aka returning bool > > > > > > > > > old := destination > > > if old = compare then > > > destination := exchange > > > return true > > > return false > > > > > > > > > I'm pretty sure it is. > > > > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > > a recent Microsoft compiler and it generates function calls. > > > But inlining should be easy enough. > > > And then 8bit and 64bit. > > > > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > > I don't know when various instructions were introduced but I know > > > 386 is much poorer here than modern processors. > > > > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > > and not e.g. floating point. > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 18 20:32:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 19:32:33 +0000 Subject: [M3devel] cas/casp? In-Reply-To: <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> , <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> Message-ID: Ah, ok. btw another "common" primitive is InterlockedCompareExchange"Double". As in InterlockedCompareExchange64 that's been in x86 a while and InterlockedCompareExchange128 that is newer. There are also often alignment requirements for these things, like to not cross cache line boundaries. We're already ok that way? At least for globals? - Jay Subject: Re: [M3devel] cas/casp? From: hosking at cs.purdue.edu Date: Fri, 18 Dec 2009 14:12:44 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 18 Dec 2009, at 14:06, Jay K wrote: oh. I already got it working. ok. Atomic confuses me in a few ways. I find it terribly confusing on Windows that there are separate compiler and memory fences. I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. It makes no sense to me to allow the processor or compiler to reorder but not both. What is weak cas? It's a CAS that can fail spuriously. i.e., even if the old value was ==. Is that loadlocked/storecondition and the caller can loop? Um. There is the Windows terminology InterlockedWhatever. There is the gccc builtins. Can we "sound" close to one of them? Or is this based on some other widely known system? The Atomic interface I posted is based on a proposal for the C++ standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html And we don't care about older x86 processors like 386?486 I assume? There seem to have been at least two leaps in functionality here. Old Win32 operating systems provide very few interlocked functions. They provide increment and decrement, that only return <0, 0, >0 of the new value. And Exchange. (This is based on the Visual C++ 2.0 winbase.h) All just on 32bit values. Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 13:32:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cas/casp? > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > GENERIC INTERFACE Atomic(Rep); > > IMPORT RTMachine; > > TYPE T = Rep.T; > > PROCEDURE MemoryFence(); > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > for other memory references wrt atomics. Not useful for ordering > ordinary memory references, since those may not race and, if they don't > race, always appear to be ordered. *) > > PROCEDURE CompilerFence(); > (* Ensures that prior memory operations appear in the instruction stream > before subsequent ones, i.e. the compiler is not allowed to reorder > around this. This really has only implementation-defined semantics, but > it seems to be useful in ensuring ordering with respect to signal > handlers and the like. *) > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > PROCEDURE StoreRelease(VAR var: T; val: T); > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > PROCEDURE LoadAcquire(READONLY var: T): T; > > TYPE Order = { Raw, Acquire, Release, Ordered }; > (* "Raw" ==> This operation is unordered, and may become visible to other > threads in an order that is constrained only by ordering constraints > on other operations. > > "Release" ==> All prior memory operations (including ordinary > assignments) become visible to a an acquire operation on the same > object that sees the resulting value. > > "Acquire" ==> See above. > > "Ordered" ==> Both acquire and release ordering properties.*) > > CONST HasCas = RTMachine.HasCas; > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > (* Most architectures provide a way to return the old value. On those that > do not, it can be emulated with an additional load, at the expense of > wait-freedom or spurious failure. *) > > CONST HasWeakCas = RTMachine.HasWeakCas; > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > provided. *) > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > CONST HasFetchOr = RTMachine.HasFetchOr; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > END Atomic. > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > Tony is this right? > > > > > > conceptually: > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > old := destination > > if old := compare then > > destination = exchange > > return old > > > > > > bool result := CASP(VAR destination, compare, exchange) > > P for predicate aka returning bool > > > > > > old := destination > > if old = compare then > > destination := exchange > > return true > > return false > > > > > > I'm pretty sure it is. > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > a recent Microsoft compiler and it generates function calls. > > But inlining should be easy enough. > > And then 8bit and 64bit. > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > I don't know when various instructions were introduced but I know > > 386 is much poorer here than modern processors. > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > and not e.g. floating point. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 21:19:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 15:19:36 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> , <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> Message-ID: <730B2897-39CC-4719-87E2-1C372FBFD734@cs.purdue.edu> On 18 Dec 2009, at 14:32, Jay K wrote: > Ah, ok. > > btw another "common" primitive is InterlockedCompareExchange"Double". > As in InterlockedCompareExchange64 that's been in x86 a while and InterlockedCompareExchange128 that is newer. > > There are also often alignment requirements for these things, like to not cross cache line boundaries. > We're already ok that way? > At least for globals? I think so. Need to check. > > - Jay > > > Subject: Re: [M3devel] cas/casp? > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 14:12:44 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > On 18 Dec 2009, at 14:06, Jay K wrote: > > oh. I already got it working. ok. > > Atomic confuses me in a few ways. > > I find it terribly confusing on Windows that there are separate compiler and memory fences. > I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. > > MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. > > It makes no sense to me to allow the processor or compiler to reorder but not both. > > > What is weak cas? > > It's a CAS that can fail spuriously. i.e., even if the old value was ==. > > Is that loadlocked/storecondition and the caller can loop? > > > Um. There is the Windows terminology InterlockedWhatever. > There is the gccc builtins. > Can we "sound" close to one of them? > Or is this based on some other widely known system? > > The Atomic interface I posted is based on a proposal for the C++ standard: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html > > And we don't care about older x86 processors like 386?486 I assume? > There seem to have been at least two leaps in functionality here. > Old Win32 operating systems provide very few interlocked functions. > They provide increment and decrement, that only return <0, 0, >0 of the new value. > And Exchange. (This is based on the Visual C++ 2.0 winbase.h) > All just on 32bit values. > > Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. > > And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. > > And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. > >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 18 Dec 2009 13:32:57 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] cas/casp? > > > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > > > GENERIC INTERFACE Atomic(Rep); > > > > IMPORT RTMachine; > > > > TYPE T = Rep.T; > > > > PROCEDURE MemoryFence(); > > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > > for other memory references wrt atomics. Not useful for ordering > > ordinary memory references, since those may not race and, if they don't > > race, always appear to be ordered. *) > > > > PROCEDURE CompilerFence(); > > (* Ensures that prior memory operations appear in the instruction stream > > before subsequent ones, i.e. the compiler is not allowed to reorder > > around this. This really has only implementation-defined semantics, but > > it seems to be useful in ensuring ordering with respect to signal > > handlers and the like. *) > > > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > > PROCEDURE StoreRelease(VAR var: T; val: T); > > > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > > PROCEDURE LoadAcquire(READONLY var: T): T; > > > > TYPE Order = { Raw, Acquire, Release, Ordered }; > > (* "Raw" ==> This operation is unordered, and may become visible to other > > threads in an order that is constrained only by ordering constraints > > on other operations. > > > > "Release" ==> All prior memory operations (including ordinary > > assignments) become visible to a an acquire operation on the same > > object that sees the resulting value. > > > > "Acquire" ==> See above. > > > > "Ordered" ==> Both acquire and release ordering properties.*) > > > > CONST HasCas = RTMachine.HasCas; > > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > > (* Most architectures provide a way to return the old value. On those that > > do not, it can be emulated with an additional load, at the expense of > > wait-freedom or spurious failure. *) > > > > CONST HasWeakCas = RTMachine.HasWeakCas; > > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > > provided. *) > > > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > > > CONST HasFetchOr = RTMachine.HasFetchOr; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > END Atomic. > > > > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > > > Tony is this right? > > > > > > > > > conceptually: > > > > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > > > > old := destination > > > if old := compare then > > > destination = exchange > > > return old > > > > > > > > > bool result := CASP(VAR destination, compare, exchange) > > > P for predicate aka returning bool > > > > > > > > > old := destination > > > if old = compare then > > > destination := exchange > > > return true > > > return false > > > > > > > > > I'm pretty sure it is. > > > > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > > a recent Microsoft compiler and it generates function calls. > > > But inlining should be easy enough. > > > And then 8bit and 64bit. > > > > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > > I don't know when various instructions were introduced but I know > > > 386 is much poorer here than modern processors. > > > > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > > and not e.g. floating point. > > > > > > > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:30:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:30:47 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. Message-ID: Here is my updated proposal for Modula-3 Atomic Word.T. These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. INTERFACE Atomic; IMPORT Word; TYPE T = Word.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = RTMachine.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:32:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:32:43 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: PS Some of these we probably can implement using existing gcc intrinsics. On 19 Dec 2009, at 18:30, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:35:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:35:31 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> Typo: FetchXAnd should read FetchAnd. On 19 Dec 2009, at 18:30, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 20 07:44:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Dec 2009 06:44:07 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> References: , <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> Message-ID: There should be a link to the C++ proposal? As well, new idea, I like the idea of source files containing a link to their cvsweb page. Not to the specific version, but something fairly "stable". - Jay From: hosking at cs.purdue.edu Date: Sat, 19 Dec 2009 18:35:31 -0500 To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. Typo: FetchXAnd should read FetchAnd. On 19 Dec 2009, at 18:30, Tony Hosking wrote: Here is my updated proposal for Modula-3 Atomic Word.T. These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. INTERFACE Atomic; IMPORT Word; TYPE T = Word.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = RTMachine.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Dec 20 04:53:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 19 Dec 2009 22:53:17 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <20091220035317.GA22518@topoi.pooq.com> On Sat, Dec 19, 2009 at 06:30:47PM -0500, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. It's not quite clear to me what these Orders mean. In particular, I don't see a clear model for the interaction of 'visibility', 'memory writes' and 'threads'. I can certainly find a ways to understand these words, but I can't be sure I understand them the same way as they are intended. Perhaps I lack context that is provided somewhere. -- hendrik From jay.krell at cornell.edu Sun Dec 20 15:57:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Dec 2009 14:57:32 +0000 Subject: [M3devel] int32 vs. integer in compare result? Message-ID: In m3front\src\misc\CG.m3: PROCEDURE Compare (t: ZType; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; cg.compare (t, Target.Integer.cg_type, op); SPop (2, "Compare"); SPush (Type.Int32); END Compare; compare(input type, output type, operation) The integrated backend ignores the output type. The gcc backend does not. Doesn't it seem like in the above, Target.Integer and Int32 should match? That compare is being asked to return a possibly larger result than the front end expects? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Dec 20 17:44:38 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 20 Dec 2009 10:44:38 -0600 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <4B2E5476.5000200@lcwb.coop> Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a > prototype implementation for the C++ memory model standardization > process. At the moment they are not gcc intrinsics, but I expect to see > that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory > locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is > affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per > "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with > "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false > while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchPlus (VAR var:T; incr: T; order := Sequential): T; Presumably -------------------^? Similarly in all the Fetch* procs. > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; Presumably ------------------------^ would be more expressive? > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is > affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use > two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise > have no > undefined behavior. *) To be legal on ADDRESS, either another parallel interface or a set of parallel procedures would be needed. Or else, this interface would have to be known to the core language and allow predefined overloading, similar to builtin operators and functions. The syntax could still be that of an interface. I don't think any existing required interfaces do this now. > > END Atomic. > > > 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 > > > > From hosking at cs.purdue.edu Sun Dec 20 19:15:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 13:15:50 -0500 Subject: [M3devel] int32 vs. integer in compare result? In-Reply-To: References: Message-ID: Yes, this seems odd... Of course, the result is supposed to be a Boolean. Will it matter? On 20 Dec 2009, at 09:57, Jay K wrote: > In m3front\src\misc\CG.m3: > > PROCEDURE Compare (t: ZType; op: Cmp) = > BEGIN > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > cg.compare (t, Target.Integer.cg_type, op); > SPop (2, "Compare"); > SPush (Type.Int32); > END Compare; > > > compare(input type, output type, operation) > > The integrated backend ignores the output type. > The gcc backend does not. > > Doesn't it seem like in the above, Target.Integer and Int32 should match? > That compare is being asked to return a possibly larger result than the > front end expects? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 20:01:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 14:01:08 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2E5476.5000200@lcwb.coop> References: <4B2E5476.5000200@lcwb.coop> Message-ID: <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> Thanks for the typo fixes. On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > To be legal on ADDRESS, either another parallel interface or a set of parallel > procedures would be needed. Or else, this interface would have to be known to > the core language and allow predefined overloading, similar to builtin operators > and functions. The syntax could still be that of an interface. I don't think > any existing required interfaces do this now. Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: GENERIC INTERFACE Atomic(Rep); TYPE T = Rep.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = Rep.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. From hosking at cs.purdue.edu Sun Dec 20 20:43:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 14:43:19 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <20091220035317.GA22518@topoi.pooq.com> References: <20091220035317.GA22518@topoi.pooq.com> Message-ID: On 19 Dec 2009, at 22:53, hendrik at topoi.pooq.com wrote: > It's not quite clear to me what these Orders mean. In particular, > I don't see a clear model for the interaction of 'visibility', 'memory > writes' and 'threads'. I can certainly find a ways to understand these > words, but I can't be sure I understand them the same way as they > are intended. > > Perhaps I lack context that is provided somewhere. These are as defined for the C++0x proposed standard. We should, of course, provide explicit description. Acquire/Release have the semantics you would expect for lock acquire and lock release: acquirers see operations performed by releasers. From rodney_bates at lcwb.coop Mon Dec 21 02:02:48 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 20 Dec 2009 19:02:48 -0600 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> References: <4B2E5476.5000200@lcwb.coop> <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> Message-ID: <4B2EC938.5030703@lcwb.coop> Tony Hosking wrote: > Thanks for the typo fixes. > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > >> To be legal on ADDRESS, either another parallel interface or a set of parallel >> procedures would be needed. Or else, this interface would have to be known to >> the core language and allow predefined overloading, similar to builtin operators >> and functions. The syntax could still be that of an interface. I don't think >> any existing required interfaces do this now. > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: And would it be illegal to try to instantiate with any other type? I presume it would have to be a native word sized value for the implementation, and the Fetch operations would not have meaning for most other types. Also, would the corresponding MODULE and its instantiations not be written in M3, but just builtin to the compiler, like Word? > > GENERIC INTERFACE Atomic(Rep); > > TYPE T = Rep.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = Rep.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > From jay.krell at cornell.edu Mon Dec 21 02:37:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 01:37:29 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2EC938.5030703@lcwb.coop> References: , <4B2E5476.5000200@lcwb.coop>, <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, <4B2EC938.5030703@lcwb.coop> Message-ID: No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). Maybe not 8, but there readily available examples of the others. Search the web for: _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). - Jay > Date: Sun, 20 Dec 2009 19:02:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > Tony Hosking wrote: > > Thanks for the typo fixes. > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > >> procedures would be needed. Or else, this interface would have to be known to > >> the core language and allow predefined overloading, similar to builtin operators > >> and functions. The syntax could still be that of an interface. I don't think > >> any existing required interfaces do this now. > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. > > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? > > > > > GENERIC INTERFACE Atomic(Rep); > > > > TYPE T = Rep.T; > > > > TYPE > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > (* "Relaxed": The operation does not order memory. > > > > "Release": Performs a release operation on the affected memory locations, > > thus making regular memory writes visible to other threads through the > > variable to which it is applied. > > > > "Acquire": Performs an acquire operation on the affected memory > > locations, thus making regular memory writes in other threads released > > through the atomic variable to which it is applied, visible to the > > current thread. > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > "Sequential": The operation has both acquire and release semantics, and > > in addition, has sequentially-consistent operation ordering. *) > > > > CONST IsLockFree = Rep.IsLockFree; > > (* True if the operations are lock-free, false otherwise. *) > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > (* Atomically replace the value in "var" with "val". Memory is affected as > > per "order". The "order" shall be neither "Acquire" nor > > "AcquireRelease". *) > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > (* Atomically return the value in "var". Memory is affected as per "order". > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > (* Atomically replace the value in "var" with "val". Returns the value of > > "var" immediately before the effects. Memory is affected as per order. > > This is a read-modify-write operation and synchronizes with any > > evaluation that reads the updated value. *) > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > desired: T; order := Order.Sequential): BOOLEAN; > > (* Atomically, compares the value in "var" for equality with that in > > "expected", and if true, replaces the value in "var" with "desired", and > > if false, updates the value in "expected" with the value in "var". > > Returns the result of the comparison. The "order" shall be neither > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > and synchronizes with any evaluation that reads the updated value. The > > effect of the CompareSwap operation is: > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > The CompareSwap operation may fail spuriously, that is return false while > > leaving the value in "expected" unchanged. A consequence of spurious > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > expected := Atomic.Load(current); > > DO > > desired := function(expected); > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > *) > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > (* Memory is affected as per "order". Synchronizes with any operation on > > the same variable. The "order" shall not be "Relaxed". *) > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > (* Atomically replace the value in "var" with the result of the operation > > applied to the value in "var" and the given operand. Memory is affected > > as per "order". These operations are read-modify-write operations and > > synchronize with any evaluation that reads the updated value. Returns > > the value of "var" immediately before the effects. > > > > For signed integral types, arithmetic is defined to use two's-complement > > representation. There are no undefined results. For address types, the > > result may be an undefined address, but the operations otherwise have no > > undefined behavior. *) > > > > END Atomic. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 21 03:23:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 21:23:37 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2EC938.5030703@lcwb.coop> References: <4B2E5476.5000200@lcwb.coop> <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> <4B2EC938.5030703@lcwb.coop> Message-ID: <8B7D053E-444A-490B-AF3D-34EA2776B40C@cs.purdue.edu> On 20 Dec 2009, at 20:02, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> Thanks for the typo fixes. >> On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: >>> To be legal on ADDRESS, either another parallel interface or a set of parallel >>> procedures would be needed. Or else, this interface would have to be known to >>> the core language and allow predefined overloading, similar to builtin operators >>> and functions. The syntax could still be that of an interface. I don't think >>> any existing required interfaces do this now. >> Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. It's an interesting question if we could instantiate with other types. For now, I am assuming not. > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? Yes, that would be the goal, though for now we will not rely on compiler support because gcc doesn't yet have everything we need. (It may have some in the existing sync builtins, but they have undefined memory ordering semantics, and probably are only meaningful on Intel x86/x86_64). > >> GENERIC INTERFACE Atomic(Rep); >> TYPE T = Rep.T; >> TYPE >> Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; >> (* "Relaxed": The operation does not order memory. >> "Release": Performs a release operation on the affected memory locations, >> thus making regular memory writes visible to other threads through the >> variable to which it is applied. >> "Acquire": Performs an acquire operation on the affected memory >> locations, thus making regular memory writes in other threads released >> through the atomic variable to which it is applied, visible to the >> current thread. >> "AcquireRelease": The operation has both acquire and release semantics. >> "Sequential": The operation has both acquire and release semantics, and >> in addition, has sequentially-consistent operation ordering. *) >> CONST IsLockFree = Rep.IsLockFree; >> (* True if the operations are lock-free, false otherwise. *) >> PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); >> (* Atomically replace the value in "var" with "val". Memory is affected as >> per "order". The "order" shall be neither "Acquire" nor >> "AcquireRelease". *) >> PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; >> (* Atomically return the value in "var". Memory is affected as per "order". >> The "order" shall be neither "Release" nor "AcquireRelease". *) >> PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; >> (* Atomically replace the value in "var" with "val". Returns the value of >> "var" immediately before the effects. Memory is affected as per order. >> This is a read-modify-write operation and synchronizes with any >> evaluation that reads the updated value. *) >> PROCEDURE CompareSwap(VAR var, expected: T; >> desired: T; order := Order.Sequential): BOOLEAN; >> (* Atomically, compares the value in "var" for equality with that in >> "expected", and if true, replaces the value in "var" with "desired", and >> if false, updates the value in "expected" with the value in "var". >> Returns the result of the comparison. The "order" shall be neither >> "Release" nor "AcquireRelease". This is a read-modify-write operation >> and synchronizes with any evaluation that reads the updated value. The >> effect of the CompareSwap operation is: >> IF var = expected THEN var := desired ELSE expected := var; >> The CompareSwap operation may fail spuriously, that is return false while >> leaving the value in "expected" unchanged. A consequence of spurious >> failure is that nearly all uses of CompareSwap will be in a loop: >> expected := Atomic.Load(current); >> DO >> desired := function(expected); >> WHILE NOT Atomic.CompareSwap(current, expected, desired); >> *) >> PROCEDURE Fence(VAR var: T; order := Order.Sequential); >> (* Memory is affected as per "order". Synchronizes with any operation on >> the same variable. The "order" shall not be "Relaxed". *) >> PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; >> PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; >> PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; >> PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; >> PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; >> (* Atomically replace the value in "var" with the result of the operation >> applied to the value in "var" and the given operand. Memory is affected >> as per "order". These operations are read-modify-write operations and >> synchronize with any evaluation that reads the updated value. Returns >> the value of "var" immediately before the effects. >> For signed integral types, arithmetic is defined to use two's-complement >> representation. There are no undefined results. For address types, the >> result may be an undefined address, but the operations otherwise have no >> undefined behavior. *) >> END Atomic. From hosking at cs.purdue.edu Mon Dec 21 03:25:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 21:25:30 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: , <4B2E5476.5000200@lcwb.coop>, <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, <4B2EC938.5030703@lcwb.coop> Message-ID: <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> If we build on the libatomic_ops support then some types might end up with (slow) implementation using locks. On 20 Dec 2009, at 20:37, Jay K wrote: > No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). > Maybe not 8, but there readily available examples of the others. > > Search the web for: > _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx > _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx > _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx > > Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). > > - Jay > > > > Date: Sun, 20 Dec 2009 19:02:48 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > > > > > Tony Hosking wrote: > > > Thanks for the typo fixes. > > > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > > >> procedures would be needed. Or else, this interface would have to be known to > > >> the core language and allow predefined overloading, similar to builtin operators > > >> and functions. The syntax could still be that of an interface. I don't think > > >> any existing required interfaces do this now. > > > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > > > And would it be illegal to try to instantiate with any other type? I presume it would > > have to be a native word sized value for the implementation, and the Fetch operations > > would not have meaning for most other types. > > > > Also, would the corresponding MODULE and its instantiations not be written in M3, > > but just builtin to the compiler, like Word? > > > > > > > > GENERIC INTERFACE Atomic(Rep); > > > > > > TYPE T = Rep.T; > > > > > > TYPE > > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > > (* "Relaxed": The operation does not order memory. > > > > > > "Release": Performs a release operation on the affected memory locations, > > > thus making regular memory writes visible to other threads through the > > > variable to which it is applied. > > > > > > "Acquire": Performs an acquire operation on the affected memory > > > locations, thus making regular memory writes in other threads released > > > through the atomic variable to which it is applied, visible to the > > > current thread. > > > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > > > "Sequential": The operation has both acquire and release semantics, and > > > in addition, has sequentially-consistent operation ordering. *) > > > > > > CONST IsLockFree = Rep.IsLockFree; > > > (* True if the operations are lock-free, false otherwise. *) > > > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > > (* Atomically replace the value in "var" with "val". Memory is affected as > > > per "order". The "order" shall be neither "Acquire" nor > > > "AcquireRelease". *) > > > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > > (* Atomically return the value in "var". Memory is affected as per "order". > > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > > (* Atomically replace the value in "var" with "val". Returns the value of > > > "var" immediately before the effects. Memory is affected as per order. > > > This is a read-modify-write operation and synchronizes with any > > > evaluation that reads the updated value. *) > > > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > > desired: T; order := Order.Sequential): BOOLEAN; > > > (* Atomically, compares the value in "var" for equality with that in > > > "expected", and if true, replaces the value in "var" with "desired", and > > > if false, updates the value in "expected" with the value in "var". > > > Returns the result of the comparison. The "order" shall be neither > > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > > and synchronizes with any evaluation that reads the updated value. The > > > effect of the CompareSwap operation is: > > > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > > > The CompareSwap operation may fail spuriously, that is return false while > > > leaving the value in "expected" unchanged. A consequence of spurious > > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > > > expected := Atomic.Load(current); > > > DO > > > desired := function(expected); > > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > > *) > > > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > > (* Memory is affected as per "order". Synchronizes with any operation on > > > the same variable. The "order" shall not be "Relaxed". *) > > > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > > (* Atomically replace the value in "var" with the result of the operation > > > applied to the value in "var" and the given operand. Memory is affected > > > as per "order". These operations are read-modify-write operations and > > > synchronize with any evaluation that reads the updated value. Returns > > > the value of "var" immediately before the effects. > > > > > > For signed integral types, arithmetic is defined to use two's-complement > > > representation. There are no undefined results. For address types, the > > > result may be an undefined address, but the operations otherwise have no > > > undefined behavior. *) > > > > > > END Atomic. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 05:24:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 04:24:13 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> References: , , <4B2E5476.5000200@lcwb.coop>, , <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, , <4B2EC938.5030703@lcwb.coop>, , <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> Message-ID: Many operations on non-words sizes are perfectly good, no locks, on x86, AMD64, IA64. _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx It's a processor thing, not an OS thing, so whatever Windows supports is trivial on any other x86/AMD64/IA64 system. - Jay From: hosking at cs.purdue.edu Date: Sun, 20 Dec 2009 21:25:30 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. If we build on the libatomic_ops support then some types might end up with (slow) implementation using locks. On 20 Dec 2009, at 20:37, Jay K wrote:No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). Maybe not 8, but there readily available examples of the others. Search the web for: _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). - Jay > Date: Sun, 20 Dec 2009 19:02:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > Tony Hosking wrote: > > Thanks for the typo fixes. > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > >> procedures would be needed. Or else, this interface would have to be known to > >> the core language and allow predefined overloading, similar to builtin operators > >> and functions. The syntax could still be that of an interface. I don't think > >> any existing required interfaces do this now. > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. > > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? > > > > > GENERIC INTERFACE Atomic(Rep); > > > > TYPE T = Rep.T; > > > > TYPE > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > (* "Relaxed": The operation does not order memory. > > > > "Release": Performs a release operation on the affected memory locations, > > thus making regular memory writes visible to other threads through the > > variable to which it is applied. > > > > "Acquire": Performs an acquire operation on the affected memory > > locations, thus making regular memory writes in other threads released > > through the atomic variable to which it is applied, visible to the > > current thread. > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > "Sequential": The operation has both acquire and release semantics, and > > in addition, has sequentially-consistent operation ordering. *) > > > > CONST IsLockFree = Rep.IsLockFree; > > (* True if the operations are lock-free, false otherwise. *) > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > (* Atomically replace the value in "var" with "val". Memory is affected as > > per "order". The "order" shall be neither "Acquire" nor > > "AcquireRelease". *) > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > (* Atomically return the value in "var". Memory is affected as per "order". > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > (* Atomically replace the value in "var" with "val". Returns the value of > > "var" immediately before the effects. Memory is affected as per order. > > This is a read-modify-write operation and synchronizes with any > > evaluation that reads the updated value. *) > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > desired: T; order := Order.Sequential): BOOLEAN; > > (* Atomically, compares the value in "var" for equality with that in > > "expected", and if true, replaces the value in "var" with "desired", and > > if false, updates the value in "expected" with the value in "var". > > Returns the result of the comparison. The "order" shall be neither > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > and synchronizes with any evaluation that reads the updated value. The > > effect of the CompareSwap operation is: > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > The CompareSwap operation may fail spuriously, that is return false while > > leaving the value in "expected" unchanged. A consequence of spurious > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > expected := Atomic.Load(current); > > DO > > desired := function(expected); > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > *) > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > (* Memory is affected as per "order". Synchronizes with any operation on > > the same variable. The "order" shall not be "Relaxed". *) > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > (* Atomically replace the value in "var" with the result of the operation > > applied to the value in "var" and the given operand. Memory is affected > > as per "order". These operations are read-modify-write operations and > > synchronize with any evaluation that reads the updated value. Returns > > the value of "var" immediately before the effects. > > > > For signed integral types, arithmetic is defined to use two's-complement > > representation. There are no undefined results. For address types, the > > result may be an undefined address, but the operations otherwise have no > > undefined behavior. *) > > > > END Atomic. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 21 10:04:36 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Dec 2009 04:04:36 -0500 Subject: [M3devel] build problems on Windows 2000 Message-ID: <4B2EC19B020000D700069A01@scires.com> I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 07:27:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: <4B2EC19B020000D700069A01@scires.com> References: <4B2EC19B020000D700069A01@scires.com> Message-ID: windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 07:38:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 06:38:33 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: References: <4B2EC19B020000D700069A01@scires.com>, Message-ID: windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 21 21:57:09 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Dec 2009 15:57:09 -0500 Subject: [M3devel] build problems on Windows 2000 Message-ID: <4B2F67D1020000D700069AC6@scires.com> Jay et al: Oops, sorry. I forgot about the SDK requirements for developing Win32 apps. BTW, seems that after Microsoft came out with the 2008 edition of Visual Studio Express, they have dropped the 2005 editions. The 2008 edition doesn't support Windows 2000, so getting the 2005 edition is a bit tricky. I managed to find a C++ 2005 edition after much searching on the web. Likewise, all the Microsoft links for the SDK now point to the newer editions which aren't compatible with Windows 2000. I've managed to find a link to the SDK and am installing it now. Thanks for your help, but we may have trouble supporting Windows 2000 in the future if folks can't get the Microsoft tools for this platform. I wonder if we would be allowed to host old versions of the tools? Regards, Randy >>> Jay K 12/21/09 1:47 AM >>> windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay
From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 .ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Verdana;} windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay
Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 22 00:25:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 23:25:17 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: <4B2F67D1020000D700069AC6@scires.com> References: <4B2F67D1020000D700069AC6@scires.com> Message-ID: Probably we cannot host the old tools. There are independent windows.h, in fact I checked them in, though I did so with a different and now abandoned goal in mind. See m3-win\w32api. We could go that route if people really want. Really I think if people want to support Windows 2000, they should have acquired compiler/linker ahead of time, or do something else like use Cygwin or DigitalMars or such. You can also find everything on eBay. The non-Express tools always come with windows.h, etc. - Jay Date: Mon, 21 Dec 2009 15:57:09 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] build problems on Windows 2000 Jay et al: Oops, sorry. I forgot about the SDK requirements for developing Win32 apps. BTW, seems that after Microsoft came out with the 2008 edition of Visual Studio Express, they have dropped the 2005 editions. The 2008 edition doesn't support Windows 2000, so getting the 2005 edition is a bit tricky. I managed to find a C++ 2005 edition after much searching on the web. Likewise, all the Microsoft links for the SDK now point to the newer editions which aren't compatible with Windows 2000. I've managed to find a link to the SDK and am installing it now. Thanks for your help, but we may have trouble supporting Windows 2000 in the future if folks can't get the Microsoft tools for this platform. I wonder if we would be allowed to host old versions of the tools? Regards, Randy >>> Jay K 12/21/09 1:47 AM >>> windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 22 18:02:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Dec 2009 17:02:23 +0000 Subject: [M3devel] head vs. release threads? Message-ID: Tony can you look at head vs. release m3core/threads and such and decide if you want all of head in release? The changes I know about are - handling low resources in pthread, the can of worms I keep prying on :) - something in user threads, I didn't read enough to understand - other stuff in user threads -- sigaltstack for openbsd I'll get Win32 -- eliminating an extra acquire/release in the InnerWait loop. Beyond that the things to consider are - assertions and dependency on time_t definition and such - keying off of processor or "os" (linux,openbsd, etc.) instead of full platform (amd64_linux, i386_openbsd, etc.) - Uconstants.c is in different order and impossible to read diff; I need to sort it or something Just copying all of head m3core to release is probably fine though I try to be a little arbitrarily slow/methodical as a substitute for being conservative, sometimes, something illogical like that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 22 18:22:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Dec 2009 12:22:04 -0500 Subject: [M3devel] head vs. release threads? In-Reply-To: References: Message-ID: <2A82B86D-732B-45AA-9E93-A142C87CFE2D@cs.purdue.edu> I thought we were aiming for stability in the release branch, rather than new functionality. My preference is to not change the release branch too much so long as fundamental functionality is there and correct... On 22 Dec 2009, at 12:02, Jay K wrote: > Tony can you look at head vs. release m3core/threads and such and decide if you want all of head in release? > The changes I know about are > - handling low resources in pthread, the can of worms I keep prying on :) > - something in user threads, I didn't read enough to understand > - other stuff in user threads -- sigaltstack for openbsd > > I'll get Win32 -- eliminating an extra acquire/release in the InnerWait loop. > > > Beyond that the things to consider are > - assertions and dependency on time_t definition and such > - keying off of processor or "os" (linux,openbsd, etc.) instead of full platform (amd64_linux, i386_openbsd, etc.) > - Uconstants.c is in different order and impossible to read diff; I need to sort it or something > > > Just copying all of head m3core to release is probably fine though I try to be a little arbitrarily > slow/methodical as a substitute for being conservative, sometimes, something illogical like that. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Dec 23 04:42:24 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Dec 2009 03:42:24 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091221150040.B051E2474001@birch.elegosoft.com> Message-ID: <770199.13762.qm@web23608.mail.ird.yahoo.com> Hi all: forgive my ignorance about the actual changes going on below copied M3commit message of Monday, December 21, 16:00:40 but what is this to have gcc code inside the compiler libs, I recommend to check the strict rules about this before performing such changes, Is there any problem getting gcc code inside the runtime libraries, even if this only used in level C code, this gets more C dependences in non-M3 code we are not able to guarantee, better UNSAFE than totally unmarked unsafe again. If this is not the case, and just a piece of m3cc related code I don't disqualify it yet. Thanks in advance --- El lun, 21/12/09, Jay Krell escribi?: > De: Jay Krell > Asunto: [M3commit] CVS Update: cm3 > Para: m3commit at elegosoft.com > Fecha: lunes, 21 de diciembre, 2009 11:00 > CVSROOT: /usr/cvs > Changes by: > jkrell at birch. 09/12/21 16:00:40 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/libgcc/: > libgcc.c > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > cm3/m3-libs/m3core/src/runtime/DS3100/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/POSIX/: > RTOSbrk.c RTOSmmap.c > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/SOLsun/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/WIN32/: > RTOSc.c > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > Log message: > add mising #ifdef cplusplus extern "C" { > } > > From dabenavidesd at yahoo.es Wed Dec 23 05:47:27 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Dec 2009 04:47:27 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <770199.13762.qm@web23608.mail.ird.yahoo.com> Message-ID: <468779.46976.qm@web23608.mail.ird.yahoo.com> Hi again: I recall to have said about a virtualization infrastructure future framework for CM3 reusing existing work made by DEC and SPIN, if we manage to get the system running as a separate process in a given processor we will be definitely getting source code level compability between UNIX implementations by means of a huge historical system like DEC UNIX and a good balance on terms of security in the Modula-3 runtime protection of foreign code. If there is no case of having user level DEC Unix server running in a host processor we can still emulate like they did and/or have a M3 Unix server inside the kernel like they planed to do. In perspective SPINE (spin development) developed a embedded system in NT kernel without touching host system processor but the actual network interface card internal processor featuring several M3 applications running on it. This would be a potential place for higher optimization in the CM3 system as we wouldn't have the usual architecture M3 guest-per system but a M3 host per system given the opportunities for it Hope this helps in something, thanks in advance --- El mar, 22/12/09, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] [M3commit] CVS Update: cm3 > Para: m3commit at elegosoft.com, jkrell at elego.de > CC: m3devel at elegosoft.com > Fecha: martes, 22 de diciembre, 2009 22:42 > Hi all: > forgive my ignorance about the actual changes going on > below copied M3commit message of Monday, December 21, > 16:00:40 but what is this to have gcc code inside the > compiler libs, I recommend to check the strict rules about > this before performing such changes, Is there any problem > getting gcc code inside the runtime libraries, even if this > only used in level C code, this gets more C dependences in > non-M3 code we are not able to guarantee, better UNSAFE than > totally unmarked unsafe again. If this is not the case, and > just a piece of m3cc related code I don't disqualify it > yet. > Thanks in advance > > --- El lun, 21/12/09, Jay Krell > escribi?: > > > De: Jay Krell > > Asunto: [M3commit] CVS Update: cm3 > > Para: m3commit at elegosoft.com > > Fecha: lunes, 21 de diciembre, 2009 11:00 > > CVSROOT: /usr/cvs > > Changes by: > > jkrell at birch. 09/12/21 16:00:40 > > > > Modified files: > > > cm3/m3-libs/m3core/src/Csupport/libgcc/: > > libgcc.c > > > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > > > > cm3/m3-libs/m3core/src/runtime/DS3100/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/POSIX/: > > RTOSbrk.c RTOSmmap.c > > > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/SOLsun/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/WIN32/: > > RTOSc.c > > > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > > > Log message: > > add mising #ifdef cplusplus > extern "C" { > > } > > > > > > > > From jay.krell at cornell.edu Wed Dec 23 11:15:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Dec 2009 10:15:51 +0000 Subject: [M3devel] libgcc.c In-Reply-To: <770199.13762.qm@web23608.mail.ird.yahoo.com> References: <20091221150040.B051E2474001@birch.elegosoft.com>, <770199.13762.qm@web23608.mail.ird.yahoo.com> Message-ID: Daniel, please look at the file. If you write the following sorts of Modula-3 code: PROCEDURE Add64(a,b: LONGINT):LONGINT= RETURN a + b; END Add64; PROCEDURE Mult64(a,b: LONGINT):LONGINT= RETURN a * b; END Mult64; PROCEDURE Div64(a,b: LONGINT):LONGINT= RETURN a / b; END Div64; Or the following sorts of C code: long long add64(long long a, long long b) { return a + b; } long long mult64(long long a, long long b) { return a * b; } long long div64(long long a, long long b) { return a / b; } fanything that does these operations, not just functions that /only/ do them, on some architectures (esp. 32 bit ones), the backend (or C compiler) will emit function calls. If gcc is the compiler/linker, it always throws libgcc.a or such, and the functions are resolved. Any C code has this property. libgcc.a is liberally licensed. Again, any C code possibly links in this code. On systems where m3cg is the backend but gcc is not the compiler/linker, e.g. SOLsun, you don't get libgcc.a, but you still get these function calls. Therefore, on a platform like SOLsun, the solution is write functions very much like the above, but with names that match what the backend emits. In fact, what might occur is Sun CC emits function calls to functions with yet other names. That's awfully inefficient (two function calls to do a multiply) but it does work. It might be good if we could teach m3cg about the function names used by other compilers/runtimes. But it's also probably only a problem on 32bit platforms and they are the past. Apparently there is some doubt as to if these functions are needed on 64bit platforms, as you can see in the comments (at least in the original). - Jay > Date: Wed, 23 Dec 2009 03:42:24 +0000 > From: dabenavidesd at yahoo.es > To: m3commit at elegosoft.com; jkrell at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hi all: > forgive my ignorance about the actual changes going on below copied M3commit message of Monday, December 21, 16:00:40 but what is this to have gcc code inside the compiler libs, I recommend to check the strict rules about this before performing such changes, Is there any problem getting gcc code inside the runtime libraries, even if this only used in level C code, this gets more C dependences in non-M3 code we are not able to guarantee, better UNSAFE than totally unmarked unsafe again. If this is not the case, and just a piece of m3cc related code I don't disqualify it yet. > Thanks in advance > > --- El lun, 21/12/09, Jay Krell escribi?: > > > De: Jay Krell > > Asunto: [M3commit] CVS Update: cm3 > > Para: m3commit at elegosoft.com > > Fecha: lunes, 21 de diciembre, 2009 11:00 > > CVSROOT: /usr/cvs > > Changes by: > > jkrell at birch. 09/12/21 16:00:40 > > > > Modified files: > > cm3/m3-libs/m3core/src/Csupport/libgcc/: > > libgcc.c > > > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > > cm3/m3-libs/m3core/src/runtime/DS3100/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/POSIX/: > > RTOSbrk.c RTOSmmap.c > > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/SOLsun/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/WIN32/: > > RTOSc.c > > > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > > > Log message: > > add mising #ifdef cplusplus extern "C" { > > } > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 23 23:50:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Dec 2009 22:50:52 +0000 Subject: [M3devel] Atomic In-Reply-To: <20091223223914.03AD02474001@birch.elegosoft.com> References: <20091223223914.03AD02474001@birch.elegosoft.com> Message-ID: Can/should we have something like AtomicWordPair or AtomicWordArray2? TYPE WordPair = RECORD a,b: Word.T END; or TYPE WordArray2 = ARRAY[0..1] of Word.T; Because modern x86 and very modern AMD64 can support Atomic.CompareExchange(WordPair). I kind of think there should also be AtomicShort or AtomicInt16 for completeness. I realize WideChar covers it, but then, char==boolean also, right? I forget what BYTESIZE(BOOLEAN) is actually. The obvious candidates are 1 and BYTESIZE(INTEGER) and 4 ("int"). For that matter..there aren't clearly 32bit operations on 64bit platforms (depending upon boolean). Which all goes to my earlier repeated point.. Atomic8, Atomic16, Atomic32, Atomic64, Atomic128, AtomicInt = Atomic32 or Atomic64, AtomicLongInt = Atomic64, AtomicWideChar = Atomic16, AtomicBool = Atomic8 or AtomicInt... - Jay > Date: Wed, 23 Dec 2009 23:39:13 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 09/12/23 23:39:13 > > Added files: > cm3/m3-libs/m3core/src/atomic/: Atomic.ig AtomicAddress.i3 > AtomicBoolean.i3 AtomicChar.i3 > AtomicInteger.i3 > AtomicLongint.i3 AtomicRefany.i3 > AtomicWideChar.i3 AtomicWord.i3 > > Log message: > Working up the Atomic interface. Comments welcome. > No implementation yet, so don't try using these... you'll get linkage errors. > But they do compile. ;-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 24 01:12:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Dec 2009 19:12:02 -0500 Subject: [M3devel] Atomic In-Reply-To: References: <20091223223914.03AD02474001@birch.elegosoft.com> Message-ID: Jay, this is Modula-3 not C. We support atomic on the Modula-3 primitive types. All of the sizes you ask for are supported. Even DCAS for 64-bit on 32-bit I Sent from my iPhone On Dec 23, 2009, at 5:50 PM, Jay K wrote: > Can/should we have something like AtomicWordPair or AtomicWordArray2? > > TYPE WordPair = RECORD a,b: Word.T END; > or TYPE WordArray2 = ARRAY[0..1] of Word.T; > > Because modern x86 and very modern AMD64 can support > Atomic.CompareExchange(WordPair). > > I kind of think there should also be AtomicShort or AtomicInt16 for > completeness. > I realize WideChar covers it, but then, char==boolean also, right? > I forget what BYTESIZE(BOOLEAN) is actually. The obvious candidates > are 1 and BYTESIZE(INTEGER) and 4 ("int"). > > For that matter..there aren't clearly 32bit operations on 64bit > platforms (depending upon boolean). > Which all goes to my earlier repeated point.. Atomic8, Atomic16, > Atomic32, Atomic64, Atomic128, AtomicInt = Atomic32 or Atomic64, > AtomicLongInt = Atomic64, AtomicWideChar = Atomic16, AtomicBool = > Atomic8 or AtomicInt... > > - Jay > > > > Date: Wed, 23 Dec 2009 23:39:13 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/12/23 23:39:13 > > > > Added files: > > cm3/m3-libs/m3core/src/atomic/: Atomic.ig AtomicAddress.i3 > > AtomicBoolean.i3 AtomicChar.i3 > > AtomicInteger.i3 > > AtomicLongint.i3 AtomicRefany.i3 > > AtomicWideChar.i3 AtomicWord.i3 > > > > Log message: > > Working up the Atomic interface. Comments welcome. > > No implementation yet, so don't try using these... you'll get > linkage errors. > > But they do compile. ;-) > > From jay.krell at cornell.edu Thu Dec 24 16:17:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Dec 2009 15:17:54 +0000 Subject: [M3devel] external two level names? Message-ID: Should we have a form of <*external*> that assumes two level names insead of one level names? This would be useful I believe for an initial implementation of Atomic. I don't see how to implement Atomic otherwise, well, other than a lame: Atomic.mg: if BYTESIZE(T) == 4 blah elsif BYTESIZE(T) == 8 blah which I guess is ok, or a switch. It'd also be very useful in the existing code base. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 24 16:35:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Dec 2009 10:35:07 -0500 Subject: [M3devel] external two level names? In-Reply-To: References: Message-ID: <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> I don't understand the question. I have a pretty good idea how to implement atomic without that. On 24 Dec 2009, at 10:17, Jay K wrote: > Should we have a form of <*external*> that assumes two level > names insead of one level names? > > This would be useful I believe for an initial implementation of Atomic. > I don't see how to implement Atomic otherwise, well, other than a lame: > > Atomic.mg: > if BYTESIZE(T) == 4 > blah > elsif BYTESIZE(T) == 8 > blah > > which I guess is ok, or a switch. > > It'd also be very useful in the existing code base. > > - Jay > > > > > From jay.krell at cornell.edu Thu Dec 24 20:57:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Dec 2009 19:57:32 +0000 Subject: [M3devel] external two level names? In-Reply-To: <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> References: , <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> Message-ID: Imagine it is implemented by actual functions and not by the compiler? Like: interface AtomicInteger; <*external AtomicInteger__FetchAdd*> PROCEDURE FetchAdd(...) <*external AtomicInteger__CompareAndSwap*> PROCEDURE CompareAndSwap(...) interface AtomicWchar; <*external AtomicWchar__FetchAdd*> PROCEDURE FetchAdd(...) <*external AtomicWchar__CompareAndSwap*> PROCEDURE CompareAndSwap(...) all by instantiating Atomic.ig. <*external*> generic interface Atomic; PROCEDURE FetchAdd(...) PROCEDURE CompareAndSwap(...) Actually I just realize the language elements are maybe there. There is already a notion of an external interface. But as I understand, in the above, every instantiation would have the same external names. How about we change generic external interfaces to be "two level"? There are situations where the existing behavior would suffice that this would break, like if you had a generic that only operated on pointers but instantiated it for multiple pointer types, in that case using the same external name for every function would be ok. I've never seen an external interface until recently when I made some, let alone a generic external interface so this probably breaks nothing. Even so, we could add syntax to external. That is, this is useful for non-generic too. Interface unix <*external unix__sleep*> PROCEDURE sleep... <*external unix__open*> PROCEDURE open... vs. <*external twolevel*> interface unix; PROCEDURE sleep... PROCEDURE open... Granted, maybe something like: AtomicImpl.i3 <* external atomic__increment8 *> procedure increment8... <* external atomic__increment16 *> procedure increment16... <* external atomic__increment32 *> procedure increment32... <* external atomic__increment64 *> procedure increment64... const something := array of bitcount = {increment8, increment16, increment32, increment64} then you can maybe index into the array by the type size log 2 and call the function...and really really hope it gets optimized to a direct call. But on the other hand...if some versions have special inlining support in the compiler anyway, then you can also just teach the compiler about a size to function name mapping and still have an "external" (non-inlined function) implementation, just with compiler support to map the names. That seems like a reasonable compromise -- "compiler support to map the names". So I'm ok with no new language mechanism, but, of course, there is that philosophy -- build reusable mechanisms, not special cases. (This seems to be a guiding principle of C++ -- instead of special casing memory, all user defined types can have destructors; like the special built in numeric types, user defined types can overload operators and have type conversions, etc.) But often the reusable mechanism is much more difficult to design and implement than some special cases. - Jay > From: hosking at cs.purdue.edu > Date: Thu, 24 Dec 2009 10:35:07 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] external two level names? > > I don't understand the question. > > I have a pretty good idea how to implement atomic without that. > > On 24 Dec 2009, at 10:17, Jay K wrote: > > > Should we have a form of <*external*> that assumes two level > > names insead of one level names? > > > > This would be useful I believe for an initial implementation of Atomic. > > I don't see how to implement Atomic otherwise, well, other than a lame: > > > > Atomic.mg: > > if BYTESIZE(T) == 4 > > blah > > elsif BYTESIZE(T) == 8 > > blah > > > > which I guess is ok, or a switch. > > > > It'd also be very useful in the existing code base. > > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 29 18:47:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Dec 2009 18:47:48 +0100 Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option Message-ID: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> Any ideas? Interaction problem between threads and select? Olaf ----- Forwarded message from bugs at elego.de ----- Date: Tue, 29 Dec 2009 16:23:23 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1080: CVSUPD server hangs if used with -C option To: @MISSING_DOMAIN #1080: CVSUPD server hangs if used with -C option -----------------------------+---------------------------------------------- Reporter: rajeshvadivelu | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: Component: sys | Version: 5.8-RC3 Severity: critical | Keywords: Relnote: | Confidential: no Org: Collabnet | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | -----------------------------+---------------------------------------------- Htr: Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package. Start the cvsupd server with -C option ./cvsupd -b /data/cvsupd -C 2 Try cvsup client to connect to the sever ./cvsup -g -L 2 /tmp/cvsupd.cfg The client connection will hang and after sometime we will get "Inactivity timeout" Fix: Env: -----------------------------+---------------------------------------------- In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the cvsup installed. The server starts find and there was no issues if I start the server without -C option. Starting cvsupd server without -C option $ ./cvsupd -b /u2/site/data/cvsupd 2009.12.29 21:31:05 IST [6225]: CVSup server started 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0 2009.12.29 21:31:05 IST [6225]: Ready to service requests Then I did a client request as below $ ./cvsup -g -L 2 /tmp/cvsupd.cfg Parsing supfile "/tmp/cvsupd.cfg" Connecting to myserver.com Connected to myserver.com Rejected by server: Access denied Will retry at 21:37:09 So the request was successful and I get a valid error message at the client. But when I start the server with -C option like the one as below, requests from client are hanging and eventually getting "Inactivity timeout" after sometime. $ ./cvsupd -b /u2/site/data/cvsupd -C 2 When ever a new client connection was made, this daemon clones another cvsupd process and it also hangs. So none of the client request were processed. Strace of the main cvsupd server process, when a new client request was fired. ----------------------------------- select(4, [3], [], [3], {0, 39000}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0, 553000}) accept(3, {sa_family=AF_INET, sin_port=htons(51221), sin_addr=inet_addr("208.75.198.60")}, [16]) = 6 setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0 setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 gettimeofday({1262103026, 146476}, NULL) = 0 open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7 fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 _llseek(7, 0, [0], SEEK_CUR) = 0 fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 close(7) = 0 gettimeofday({1262103026, 147481}, NULL) = 0 stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No such file or directory) write(5, "\0", 1) = 1 futex(0x91580f0, FUTEX_WAKE, 1) = 1 futex(0x9158098, FUTEX_WAKE, 1) = 1 futex(0x91580b8, FUTEX_WAKE, 1) = 1 futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x9158098, FUTEX_WAKE, 1) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f43708) = 6543 futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1 futex(0x915a460, FUTEX_WAKE, 1) = 1 futex(0x91580f0, FUTEX_WAKE, 1) = 1 futex(0x9158098, FUTEX_WAKE, 1) = 1 futex(0x91580b8, FUTEX_WAKE, 1) = 1 futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x9158098, FUTEX_WAKE, 1) = 0 close(6) = 0 accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) ------------------------------------ gdb backtrace of the main cvsupd server process ------------------------------------ #0 0x00a2a402 in __kernel_vsyscall () #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6 #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78, writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at ../src/unix/Common/UnixC.c:301 #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0xbfed9410) at ../src/thread/PTHREAD/ThreadPThread.m3:900 #4 0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:936 #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:854 #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48, M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458 #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at ../src/FSServer.m3:153 #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:399 #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:113 #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at ../src/runtime/common/RTLinker.m3:122 #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at _m3main.mc:4 ------------------------------------------------ strace of the cloned cvsupd process ----------------------------------- futex(0x91580bc, FUTEX_WAIT, 3, NULL ----------------------------------- gdb backtrace of the cloned cvsupd process ----------------------------------- #0 0x00a2a402 in __kernel_vsyscall () #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8, mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #3 0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c, M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238 #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #5 0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc, M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105 #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243 #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at ../src/FSServer.m3:231 #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at ../src/FSServer.m3:227 #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:399 #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:113 #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at ../src/runtime/common/RTLinker.m3:122 #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at _m3main.mc:4 ------------------------------------------- So it looks like both the main and cloned cvsupd processes were waiting for a response from the kernel call "__kernel_vsyscall ()". Under what condition will this happen? Am I doing something wrong here? -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 From rcolebur at SCIRES.COM Wed Dec 30 01:30:17 2009 From: rcolebur at SCIRES.COM (Randy Coleburn) Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages Message-ID: I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 14:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 13:10:55 +0000 Subject: [M3devel] build problems on 3 packages In-Reply-To: References: Message-ID: I haven't checked obliqparse or caltech-parser yet but I see what you mean in obliqrt. I haven't dug into it yet. == package /Users/jay/dev2/cm3/m3-obliq/obliqrt == +++ /cm3/bin/cm3 -build -override -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in AMD64_DARWIN --- ignoring override("obliqrt", "/Users/jay/dev2/cm3/m3-obliq") /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB "/Users/jay/dev2/cm3/m3-libs/m3core/src/text/Text.i3", line 16,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Real.i3", line 11,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/LongReal.i3", line 10,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Extended.i3", line 9,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/libm3/src/fmtlex/Fmt.i3", line 17,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/events/src/EventNumber.i3", line 78,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/sharedobj/src/SharedObj.i3", line 179,0: semantic analysis suppressed due to import errors "../src/ObValue.i3", line 6,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 1: /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB --procedure-- -line- -file--- exec -- _v_netobj 37 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobjv1 44 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobj 64 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl include_dir 45 /Users/jay/dev2/cm3/m3-obliq/obliqrt/src/m3makefile 9 /Users/jay/dev2/cm3/m3-obliq/obliqrt/AMD64_DARWIN/m3make.args Fatal Error: package build failed *** execution of [] failed *** - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 15:50:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 14:50:35 +0000 Subject: [M3devel] build problems on 3 packages In-Reply-To: References: , Message-ID: Please try again, thanks. These were presumably caught by tinderbox though I didn't check. - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Wed, 30 Dec 2009 13:10:55 +0000 Subject: Re: [M3devel] build problems on 3 packages I haven't checked obliqparse or caltech-parser yet but I see what you mean in obliqrt. I haven't dug into it yet. == package /Users/jay/dev2/cm3/m3-obliq/obliqrt == +++ /cm3/bin/cm3 -build -override -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in AMD64_DARWIN --- ignoring override("obliqrt", "/Users/jay/dev2/cm3/m3-obliq") /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB "/Users/jay/dev2/cm3/m3-libs/m3core/src/text/Text.i3", line 16,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Real.i3", line 11,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/LongReal.i3", line 10,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Extended.i3", line 9,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/libm3/src/fmtlex/Fmt.i3", line 17,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/events/src/EventNumber.i3", line 78,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/sharedobj/src/SharedObj.i3", line 179,0: semantic analysis suppressed due to import errors "../src/ObValue.i3", line 6,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 1: /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB --procedure-- -line- -file--- exec -- _v_netobj 37 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobjv1 44 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobj 64 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl include_dir 45 /Users/jay/dev2/cm3/m3-obliq/obliqrt/src/m3makefile 9 /Users/jay/dev2/cm3/m3-obliq/obliqrt/AMD64_DARWIN/m3make.args Fatal Error: package build failed *** execution of [] failed *** - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 20:46:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 19:46:18 +0000 Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option In-Reply-To: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> Message-ID: There should be nothing special about select and kernel threads, perhaps even select and user threads. The bug report is unusually good, though lacks the config file and the stacks of the other threads. Maybe more later.. - Jay > Date: Tue, 29 Dec 2009 18:47:48 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option > > Any ideas? Interaction problem between threads and select? > > Olaf > > ----- Forwarded message from bugs at elego.de ----- > Date: Tue, 29 Dec 2009 16:23:23 -0000 > From: CM3 > Reply-To: CM3 > Subject: [CM3] #1080: CVSUPD server hangs if used with -C option > To: @MISSING_DOMAIN > > #1080: CVSUPD server hangs if used with -C option > -----------------------------+---------------------------------------------- > Reporter: rajeshvadivelu | Owner: wagner > Type: sw-bug | Status: new > Priority: high | Milestone: > Component: sys | Version: 5.8-RC3 > Severity: critical | Keywords: > Relnote: | Confidential: no > Org: Collabnet | Estimatedhours: 0 > Hours: 0 | Billable: 0 > Totalhours: 0 | > -----------------------------+---------------------------------------------- > Htr: > Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package. > > Start the cvsupd server with -C option > > ./cvsupd -b /data/cvsupd -C 2 > > Try cvsup client to connect to the sever > > ./cvsup -g -L 2 /tmp/cvsupd.cfg > > The client connection will hang and after sometime we will get > "Inactivity timeout" > > > Fix: > > > > Env: > > > -----------------------------+---------------------------------------------- > In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs > repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the > cvsup installed. > > The server starts find and there was no issues if I start the server > without -C option. > > Starting cvsupd server without -C option > > $ ./cvsupd -b /u2/site/data/cvsupd > 2009.12.29 21:31:05 IST [6225]: CVSup server started > 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46 > 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0 > 2009.12.29 21:31:05 IST [6225]: Ready to service requests > > Then I did a client request as below > > $ ./cvsup -g -L 2 /tmp/cvsupd.cfg > Parsing supfile "/tmp/cvsupd.cfg" > Connecting to myserver.com > Connected to myserver.com > Rejected by server: Access denied > Will retry at 21:37:09 > > So the request was successful and I get a valid error message at the > client. > > But when I start the server with -C option like the one as below, requests > from client are hanging and eventually getting "Inactivity timeout" after > sometime. > > $ ./cvsupd -b /u2/site/data/cvsupd -C 2 > > When ever a new client connection was made, this daemon clones another > cvsupd process and it also hangs. So none of the client request were > processed. > > Strace of the main cvsupd server process, when a new client request was > fired. > > ----------------------------------- > select(4, [3], [], [3], {0, 39000}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0, 553000}) > accept(3, {sa_family=AF_INET, sin_port=htons(51221), > sin_addr=inet_addr("208.75.198.60")}, [16]) = 6 > setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0 > setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) > fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 > gettimeofday({1262103026, 146476}, NULL) = 0 > open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7 > fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 > _llseek(7, 0, [0], SEEK_CUR) = 0 > fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 > close(7) = 0 > gettimeofday({1262103026, 147481}, NULL) = 0 > stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No > such file or directory) > write(5, "\0", 1) = 1 > futex(0x91580f0, FUTEX_WAKE, 1) = 1 > futex(0x9158098, FUTEX_WAKE, 1) = 1 > futex(0x91580b8, FUTEX_WAKE, 1) = 1 > futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0x9158098, FUTEX_WAKE, 1) = 0 > clone(child_stack=0, > flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0xb7f43708) = 6543 > futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1 > futex(0x915a460, FUTEX_WAKE, 1) = 1 > futex(0x91580f0, FUTEX_WAKE, 1) = 1 > futex(0x9158098, FUTEX_WAKE, 1) = 1 > futex(0x91580b8, FUTEX_WAKE, 1) = 1 > futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0x9158098, FUTEX_WAKE, 1) = 0 > close(6) = 0 > accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource temporarily > unavailable) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > > ------------------------------------ > > gdb backtrace of the main cvsupd server process > > ------------------------------------ > > #0 0x00a2a402 in __kernel_vsyscall () > #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6 > #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78, > writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at > ../src/unix/Common/UnixC.c:301 > #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4, > M3_A4bqCj_timeout=0xbfed9410) at > ../src/thread/PTHREAD/ThreadPThread.m3:900 > #4 0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c, > M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:936 > #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3, > M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at > ../src/thread/PTHREAD/ThreadPThread.m3:854 > #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48, > M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458 > #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at > ../src/FSServer.m3:153 > #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 > #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:399 > #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:113 > #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at > ../src/runtime/common/RTLinker.m3:122 > #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at > _m3main.mc:4 > ------------------------------------------------ > > > strace of the cloned cvsupd process > > ----------------------------------- > > futex(0x91580bc, FUTEX_WAIT, 3, NULL > > ----------------------------------- > > gdb backtrace of the cloned cvsupd process > > ----------------------------------- > > #0 0x00a2a402 in __kernel_vsyscall () > #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/libpthread.so.0 > #2 0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8, > mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 > #3 0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c, > M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238 > #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8, > M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280 > #5 0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc, > M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105 > #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243 > #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at > ../src/FSServer.m3:231 > #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at > ../src/FSServer.m3:227 > #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 > #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:399 > #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:113 > #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at > ../src/runtime/common/RTLinker.m3:122 > #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at > _m3main.mc:4 > > ------------------------------------------- > > So it looks like both the main and cloned cvsupd processes were waiting > for a response from the kernel call "__kernel_vsyscall ()". Under what > condition will this happen? Am I doing something wrong here? > > -- > Ticket URL: > CM3 > Critical Mass Modula3 Compiler > > > ----- End forwarded message ----- > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 09:18:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:18:08 +0000 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: Oh darn, some hiccup on my phone has caused a bunch of emails to resent. Sorry for the horrendous noise. :( - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 02:02:47 +0000 > Subject: Re: [M3devel] This is a pixmap? > > > Trying again due to truncation. > > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: This is a pixmap? > Date: Thu, 3 Sep 2009 15:44:17 +0000 > > > > Does this look like a pixmap to anyone? > This is the parameter to Win32 Join. > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > t is at @ebp + here. > The pointer then is 00200000 at the start of the second line of the second dump. > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 09:31:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:31:21 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091130160501.GA24572@topoi.pooq.com> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu>, <20091130160501.GA24572@topoi.pooq.com> Message-ID: There certainly is such a campain in general. It has a few "labels". Posix glibc BSD sockets Mono C stdio.h gcc As well as "Linux" and "NT". The challenge then is weaving your way around options such as: chosing a very small number of systems, e.g. just NT chosing a very small number of features, e.g. stdio.h layering on some interface that you believe you can implement on top of multiple other systems e.g. Thread.i3, ThreadWin32.m3, ThreadPThread.m3 with various qualities, costs (maintenance, performance), etc. e.g. Trestle e.g. garbage collection (esp. when combined with Thread.i3) There is no one easy answer here. It helps that "chosing a very small number of systems" is a popular choice, thereby narrowing the field, unless you are/were one of the less popular systems. :) - Jay > Date: Mon, 30 Nov 2009 11:05:01 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > CC: hendrik at topoi.pooq.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > On Mon, Nov 30, 2009 at 09:48:48AM -0500, Tony Hosking wrote: > > This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. > > There seems to be a campaign to make all OS's behave the same to the > lowest possible code level. The only way to do that is to restrict > ourselves to a subset of their facilities that all share. I suspect > this is too restrictive. For popular platforms, at least, we should be > open to implement Modula 3 library features in a way that takes > advantage of those platforms peculiar abilities -- provided that the > library-user facilities remain compatible of course. > > That said, Windows is a popular platform that I have no use for (Windows > won't even install on my most-used machine -- for some obscure reason > it will only run in maintenance mode; my daughter says the machine is > corsed). The only thing I need Windows for is writing programs that > are to uised by other people. For that purpose, I do care that any > Modula 3 applications I write can be cross-compiled (ideally) and > immediately run properly on Windows without modification. > > But I suspect that is too much to expect in the real world, even with > the uncanny competence with which Modula 3 system is put togeter. > > -- hendrik > > > > > On 30 Nov 2009, at 13:03, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 09/11/30 13:03:07 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > > > > > Log message: > > > keep two thread handles > > > what to call them is unclear > > > here we ahve: > > > joinHandle > > > suspendResumeHandle > > > > > > aka: > > > pthread > > > ntthread > > > > > > on all but Interix (and possibly Cygwin), they are equivalent, > > > either the result of pthread_create or pthread_self > > > > > > on Interix, once is pthread_create/self, the other is a kernel handle > > > for suspend/resume > > > > > > alternate names welcome > > > the intent seems hoky, but helps much > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 09:43:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 08:43:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <6CED57F2-7E8F-4D7C-8DD0-8AE436BEF31B@cs.purdue.edu> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu>, <20091130160501.GA24572@topoi.pooq.com>, <6CED57F2-7E8F-4D7C-8DD0-8AE436BEF31B@cs.purdue.edu> Message-ID: Interest in Interix would probably track similarly with interest in Cygwin. They each have pluses and minuses. Interix in particular has a "normal" fast fork and is therefore far less unpleasant to use, esp. building m3cc. (Tip for Interix users: "net stop beep". I find Interix beeps a lot and the volume can't be controlled or muted (using the normal methods), such as when tab doesn't have anything to complete, etc.) - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 13:21:39 -0500 To: hendrik at topoi.pooq.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I was really just asking what the Interix target was good for. Windows users will want Windows integration, right? Rather than the Interix hybrid... On 30 Nov 2009, at 11:05, hendrik at topoi.pooq.com wrote: On Mon, Nov 30, 2009 at 09:48:48AM -0500, Tony Hosking wrote: This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. There seems to be a campaign to make all OS's behave the same to the lowest possible code level. The only way to do that is to restrict ourselves to a subset of their facilities that all share. I suspect this is too restrictive. For popular platforms, at least, we should be open to implement Modula 3 library features in a way that takes advantage of those platforms peculiar abilities -- provided that the library-user facilities remain compatible of course. That said, Windows is a popular platform that I have no use for (Windows won't even install on my most-used machine -- for some obscure reason it will only run in maintenance mode; my daughter says the machine is corsed). The only thing I need Windows for is writing programs that are to uised by other people. For that purpose, I do care that any Modula 3 applications I write can be cross-compiled (ideally) and immediately run properly on Windows without modification. But I suspect that is too much to expect in the real world, even with the uncanny competence with which Modula 3 system is put togeter. -- hendrik On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 11:06:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 10:06:46 +0000 Subject: [M3devel] Interix In-Reply-To: <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> Message-ID: I should point out that, like NT386, NT386GNU, NT386MINGNU, Interix is also in reality a few variables that can be mixed/matched. You can use either gcc or Visual C++ compiler and linker, and either the gcc backend or the integrated backend. In Interix, gcc is gcc (3.x or possibly 4.2), and cc is a wrapper around Visual C++ cl/link. They both work. For most code, indistinguishably, though definitely a little bit different feature sets. Interix does /not/, at least on XP, provide the other variables like C runtime, threading library, GUI library. After XP they do support "mixed mode" -- access to Win32 -- so then those choices would come back maybe. To help cc work, you can point $C89_COMPILER and $C89_LINKER at Visual C++ compiler/linker. (Similarly, you know, Intel has a compiler you can use on as I understand, Windows, Linux, MacOSX, x86, amd64, ia64?. I'm not sure it gets as much use as either gcc or Visual C++, but it is out there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; jkrell at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 30 Nov 2009 18:15:49 +0000 Interix is Posix (mostly) on NT, with fast fork. Cygwin in comparison is very slow. However SIGINFO is not available. Nor is "direct suspend" using a pthread_t I believe. The older Interix version on XP does not allow access to any Win32 functions. Newer versions do. This does seem to be a pretty useful platfom. Gui should be available too, but I have to work around some problem. - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 09:48:48 -0500 To: jkrell at elego.de CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Dec 1 12:01:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Dec 2009 06:01:54 -0500 Subject: [M3devel] Interix In-Reply-To: References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> Message-ID: <4B14B071.1E75.00D7.1@scires.com> Just out of curiosity, is anyone in the M3 community using or planning to use Interix ? I only plan to use native Windows, not Interix and not Cygwin. If no one wants Interix, perhaps current Interix efforts should be put on hold until the release is completed? Regards, Randy >>> Jay K 12/1/2009 5:06 AM >>> I should point out that, like NT386, NT386GNU, NT386MINGNU, Interix is also in reality a few variables that can be mixed/matched. You can use either gcc or Visual C++ compiler and linker, and either the gcc backend or the integrated backend. In Interix, gcc is gcc (3.x or possibly 4.2), and cc is a wrapper around Visual C++ cl/link. They both work. For most code, indistinguishably, though definitely a little bit different feature sets. Interix does /not/, at least on XP, provide the other variables like C runtime, threading library, GUI library. After XP they do support "mixed mode" -- access to Win32 -- so then those choices would come back maybe. To help cc work, you can point $C89_COMPILER and $C89_LINKER at Visual C++ compiler/linker. (Similarly, you know, Intel has a compiler you can use on as I understand, Windows, Linux, MacOSX, x86, amd64, ia64?. I'm not sure it gets as much use as either gcc or Visual C++, but it is out there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; jkrell at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 30 Nov 2009 18:15:49 +0000 Interix is Posix (mostly) on NT, with fast fork. Cygwin in comparison is very slow. However SIGINFO is not available. Nor is "direct suspend" using a pthread_t I believe. The older Interix version on XP does not allow access to any Win32 functions. Newer versions do. This does seem to be a pretty useful platfom. Gui should be available too, but I have to work around some problem. - Jay From: hosking at cs.purdue.edu Date: Mon, 30 Nov 2009 09:48:48 -0500 To: jkrell at elego.de CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 This whole interix thing is pretty messy. Why do we care? If you are on Windows just use Windows threads. No need to pollute the pthreads code base with unnecessary complications for weird hybrids. On 30 Nov 2009, at 13:03, Jay Krell wrote: CVSROOT:/usr/cvs Changes by:jkrell at birch.09/11/30 13:03:07 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: keep two thread handles what to call them is unclear here we ahve: joinHandle suspendResumeHandle aka: pthread ntthread on all but Interix (and possibly Cygwin), they are equivalent, either the result of pthread_create or pthread_self on Interix, once is pthread_create/self, the other is a kernel handle for suspend/resume alternate names welcome the intent seems hoky, but helps much -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 1 12:01:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Dec 2009 11:01:10 +0000 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: I don't know if this is my phone or the mail server. Let's try turning off phone.. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 02:02:47 +0000 > Subject: Re: [M3devel] This is a pixmap? > > > Trying again due to truncation. > > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: This is a pixmap? > Date: Thu, 3 Sep 2009 15:44:17 +0000 > > > > Does this look like a pixmap to anyone? > This is the parameter to Win32 Join. > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > t is at @ebp + here. > The pointer then is 00200000 at the start of the second line of the second dump. > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 1 13:44:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Dec 2009 13:44:15 +0100 Subject: [M3devel] Final release sprint? was: Re: Interix In-Reply-To: <4B14B071.1E75.00D7.1@scires.com> References: <20091130120307.D45102474001@birch.elegosoft.com>, <8B437E5C-B1CE-4F39-AC8E-517005211772@cs.purdue.edu> <4B14B071.1E75.00D7.1@scires.com> Message-ID: <20091201134415.nk1fd6m59w8ocscg@mail.elegosoft.com> Quoting Randy Coleburn : > Just out of curiosity, is anyone in the M3 community using or > planning to use Interix ? > > I only plan to use native Windows, not Interix and not Cygwin. > > If no one wants Interix, perhaps current Interix efforts should be > put on hold until the release is completed? I really don't want to patronize anyone regarding his or her work on CM3, but it seems to be extremely difficult to concentrate the efforts on bringing the release engineering for 5.8 to an end. I currently cannot spend much time at all, and there are still several open tickets. I also haven't seen much (not to say none) feedback on the RC4 archives which are (mostly, some target platforms are still missing) available for several weeks. But in the meantime continuous integration has broken down several times on the release branch, so there must have been significant changes again. Very likely this release has already taken much too long, so that nobody is really interested anymore. It would be a pity if we don't get anything out the door though, as it will without doubt be much better than what was available before. As I said before, I'm unlikely to do any serious investigation or fixing during the next weeks. I can just have a look at the CI and ticket status now and then. If anybody wants to take over release engineering here, that would be OK for me, too; but I think that's rather unlikely, as I only volunteered because there was noone else ;-) So to summarize, I wouldn't say that nobody wants Interix or that it isn't worth the efforts, but I'd really appreciate if we could concentrate our efforts to finish the release. 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 From rodney_bates at lcwb.coop Tue Dec 1 16:35:48 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 01 Dec 2009 09:35:48 -0600 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <4B1537D4.8000909@lcwb.coop> I don't think it is your phone, because I happen to have changed the email address I use in my subscriptions, and the duplicate messages are all coming to the old email address. Must be the list server. Jay K wrote: > I don't know if this is my phone or the mail server. > Let's try turning off phone.. > > - Jay > > From rcoleburn at scires.com Tue Dec 1 20:32:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Dec 2009 14:32:21 -0500 Subject: [M3devel] build problem diagnosis in caltech-parser test package Message-ID: <4B150A90020000D700067FB8@scires.com> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 2 05:12:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Dec 2009 23:12:09 -0500 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> OK, this is getting ridiculous. Can someone at Elego give the mail-list server a poke to make sure it is not them resending as middle-man? Jay, do you have any ideas what could be going on at your end? On 3 Sep 2009, at 11:44, Jay K wrote: > > Does this look like a pixmap to anyone? > > This is the parameter to Win32 Join. > > > > PROCEDURE Join(t: T): REFANY = > VAR res: REFANY; > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; > WHILE NOT t.completed DO Wait(threadMu, t.cond) END; > res := t.result; > t.result := NIL; > t.joined := TRUE; > t.cond := NIL; > IF perfOn THEN PerfChanged(t.id, State.dead) END; > END; > RETURN res; > END Join; > > > Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. > > t is at @ebp + here. > > The pointer then is 00200000 at the start of the second line of the second dump. > > > > If we can confirm this is pixmap, we can hunt more around in the gui code -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Wed Dec 2 06:12:20 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 01 Dec 2009 21:12:20 -0800 Subject: [M3devel] This is a pixmap? In-Reply-To: References: Message-ID: <20091202051220.E3A5D1A205E@async.async.caltech.edu> Why is this message looping over and over? This and another from Jay of the same day.. I must have received hundreds of copies by now. The messages are dated September 3 and 4. Mika Jay K writes: >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Trying again due to truncation. > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: m3devel at elegosoft.com >Subject: This is a pixmap? >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 > > > >Does this look like a pixmap to anyone? >This is the parameter to Win32 Join. >=20 >PROCEDURE Join(t: T): REFANY =3D > VAR res: REFANY=3B > BEGIN > LOCK threadMu DO > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= >")=3B END=3B > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B > res :=3D t.result=3B > t.result :=3D NIL=3B > t.joined :=3D TRUE=3B > t.cond :=3D NIL=3B > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B > END=3B > RETURN res=3B > END Join=3B > >Very very often the crash is of the form of reading a pointer from 16 bytes= > into t and dereferencing it=2C plus or minus 4. >t is at @ebp + here. >The pointer then is 00200000 at the start of the second line of the second = >dump. >=20 >If we can confirm this is pixmap=2C we can hunt more around in the gui code= From jay.krell at cornell.edu Wed Dec 2 06:49:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Dec 2009 05:49:08 +0000 Subject: [M3devel] frequently recurring emails In-Reply-To: <20091202051220.E3A5D1A205E@async.async.caltech.edu> References: , <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: I don't know what is happening here but I don't think it is from me. On my end: - none of the messages are signed "phone" so not phone - I turned my phone off for hours so not phone ? - Jay > To: jay.krell at cornell.edu > Date: Tue, 1 Dec 2009 21:12:20 -0800 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] This is a pixmap? > > > Why is this message looping over and over? This and another from > Jay of the same day.. I must have received hundreds of copies by now. > The messages are dated September 3 and 4. > > Mika > > Jay K writes: > >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Trying again due to truncation. > > > >=20 > > > > - Jay > >=20 > > > > > >From: jay.krell at cornell.edu > >To: m3devel at elegosoft.com > >Subject: This is a pixmap? > >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 > > > > > > > >Does this look like a pixmap to anyone? > >This is the parameter to Win32 Join. > >=20 > >PROCEDURE Join(t: T): REFANY =3D > > VAR res: REFANY=3B > > BEGIN > > LOCK threadMu DO > > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= > >")=3B END=3B > > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B > > res :=3D t.result=3B > > t.result :=3D NIL=3B > > t.joined :=3D TRUE=3B > > t.cond :=3D NIL=3B > > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B > > END=3B > > RETURN res=3B > > END Join=3B > > > >Very very often the crash is of the form of reading a pointer from 16 bytes= > > into t and dereferencing it=2C plus or minus 4. > >t is at @ebp + here. > >The pointer then is 00200000 at the start of the second line of the second = > >dump. > >=20 > >If we can confirm this is pixmap=2C we can hunt more around in the gui code= -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Wed Dec 2 09:23:44 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Dec 2009 09:23:44 +0100 Subject: [M3devel] frequently recurring emails In-Reply-To: References: , <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: <20091202092344.rw3vpecq74gocg4g@mail.elego.de> ...looking into it. -Mike Quoting Jay K : > > I don't know what is happening here but I don't think it is from me. > > On my end: > > - none of the messages are signed "phone" so not phone > > - I turned my phone off for hours so not phone > > ? > > > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Tue, 1 Dec 2009 21:12:20 -0800 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] This is a pixmap? >> >> >> Why is this message looping over and over? This and another from >> Jay of the same day.. I must have received hundreds of copies by now. >> The messages are dated September 3 and 4. >> >> Mika >> >> Jay K writes: >> >--_b2b74cea-5620-4d48-92d7-cba16dcb3507_ >> >Content-Type: text/plain; charset="iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Trying again due to truncation. >> > >> >=20 >> > >> > - Jay >> >=20 >> > >> > >> >From: jay.krell at cornell.edu >> >To: m3devel at elegosoft.com >> >Subject: This is a pixmap? >> >Date: Thu=2C 3 Sep 2009 15:44:17 +0000 >> > >> > >> > >> >Does this look like a pixmap to anyone? >> >This is the parameter to Win32 Join. >> >=20 >> >PROCEDURE Join(t: T): REFANY =3D >> > VAR res: REFANY=3B >> > BEGIN >> > LOCK threadMu DO >> > IF t.joined THEN Die(ThisLine()=2C "attempt to join with thread twice= >> >")=3B END=3B >> > WHILE NOT t.completed DO Wait(threadMu=2C t.cond) END=3B >> > res :=3D t.result=3B >> > t.result :=3D NIL=3B >> > t.joined :=3D TRUE=3B >> > t.cond :=3D NIL=3B >> > IF perfOn THEN PerfChanged(t.id=2C State.dead) END=3B >> > END=3B >> > RETURN res=3B >> > END Join=3B >> > >> >Very very often the crash is of the form of reading a pointer from >> 16 bytes= >> > into t and dereferencing it=2C plus or minus 4. >> >t is at @ebp + here. >> >The pointer then is 00200000 at the start of the second line of >> the second = >> >dump. >> >=20 >> >If we can confirm this is pixmap=2C we can hunt more around in the >> gui code= > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Dec 2 10:03:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 10:03:31 +0100 Subject: [M3devel] Mail problems, was: Re: This is a pixmap? In-Reply-To: <20091202051220.E3A5D1A205E@async.async.caltech.edu> References: <20091202051220.E3A5D1A205E@async.async.caltech.edu> Message-ID: <20091202100331.ho1xpesj4s408kc4@mail.elegosoft.com> Quoting Mika Nystrom : > Why is this message looping over and over? This and another from > Jay of the same day.. I must have received hundreds of copies by now. > The messages are dated September 3 and 4. This is strange. I didn't get hundreds of copies so I didn't really notice the problem. Mike is already investigating. If there is anything wrong with our services, please remember to include admins at elego.de, or at least m3-support at elego.de, or directly manderson at elego.de in your To: address. That will speed up the process. 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 From peter.mckinna at gmail.com Wed Dec 2 12:17:44 2009 From: peter.mckinna at gmail.com (peter mckinna) Date: Wed, 2 Dec 2009 22:17:44 +1100 Subject: [M3devel] Coverage tools Message-ID: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> Hi, Does the coverage tool actually work? I tried compiling with the -Z option after fixing up the C code in m3-tools/coverage but no luck. Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 2 12:56:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 12:56:35 +0100 Subject: [M3devel] Coverage tools In-Reply-To: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> References: <3d9e5afc0912020317w6cc491dbpd737f17154842953@mail.gmail.com> Message-ID: <20091202125635.dcg5bwuo9sgc0wco@mail.elegosoft.com> Quoting peter mckinna : > Hi, > > Does the coverage tool actually work? > > I tried compiling with the -Z option after fixing up the C code in > m3-tools/coverage but no luck. I cannot say. It is probably legacy code from SRC that has not been used for many years and may fail due to various reasons now. We should probably document that. Can you also open a ticket (low priority) for the issue in trac? 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 From michael.anderson at elego.de Wed Dec 2 15:51:08 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Dec 2009 15:51:08 +0100 Subject: [M3devel] This is a pixmap? In-Reply-To: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> References: <70A7C070-0025-4B83-AC35-24F49D3638F2@cs.purdue.edu> Message-ID: <20091202155108.let6ez86s8osgkc4@mail.elego.de> Hi All, The problem is on our end, not Jay's. I've identified the cause and am cleaning up now. Sorry for the spam. -Mike Quoting Tony Hosking : > OK, this is getting ridiculous. Can someone at Elego give the > mail-list server a poke to make sure it is not them resending as > middle-man? Jay, do you have any ideas what could be going on at > your end? > > On 3 Sep 2009, at 11:44, Jay K wrote: > >> >> Does this look like a pixmap to anyone? >> >> This is the parameter to Win32 Join. >> >> >> >> PROCEDURE Join(t: T): REFANY = >> VAR res: REFANY; >> BEGIN >> LOCK threadMu DO >> IF t.joined THEN Die(ThisLine(), "attempt to join with thread >> twice"); END; >> WHILE NOT t.completed DO Wait(threadMu, t.cond) END; >> res := t.result; >> t.result := NIL; >> t.joined := TRUE; >> t.cond := NIL; >> IF perfOn THEN PerfChanged(t.id, State.dead) END; >> END; >> RETURN res; >> END Join; >> >> >> Very very often the crash is of the form of reading a pointer from >> 16 bytes into t and dereferencing it, plus or minus 4. >> >> t is at @ebp + here. >> >> The pointer then is 00200000 at the start of the second line of the >> second dump. >> >> >> >> If we can confirm this is pixmap, we can hunt more around in the gui code > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Wed Dec 2 18:01:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 2 Dec 2009 09:01:49 -0800 (PST) Subject: [M3devel] Looking to update cm3 manual page. Message-ID: <538131.35719.qm@web56806.mail.re3.yahoo.com> Hi all, It has been more than half a year since I last looked at the CM3 manual page. I am now looking at the it in preparation for the release of version 5.8, and noticing some deficiencies. I asking for help in identifying any further places it is lacking. I can integrate any feedback into a revised manual page, and submit an updated version back to the archives. Currently identified deficiencies: o The manual page should explicitly state which version of the compiler it documents. o The sub-section "Expected Directory Structure" needs a better discussion, especially an introduction. o The discussion of mode option "-ship" mentions environment variable CM3_INSTALL_ROOT, yet in cm3.cfg we set INSTALL_ROOT without the "CM3_" prefix. This should be resolved. ** What is the exact meaning of these two? Is one recognized by the compiler, and the other by the supporting quake code? o The ENVIRONMENT section does not mention CM3_INSTALL_ROOT at all. Add a discussion about both INSTALL_ROOT, and CM3_INSTALL_ROOT. ** Am I missing any other environment variables? o Missing command line options for the compiler: - I currently have "-g", but no discussion of -gstabs. No discussion about not supporting DWARF (or do we?). o Compiler unique language features, (i.e., pragmas). The reference books (Nelson, and Harbison) give a list of suggested pragmas. The manual page should list the ones supported by the CM3 compiler explicitly, and show their syntax. ** Can someone list for me the pragmas supported by the current (5.8.4) compiler. o Should list any limitations of either the compiler, or the library suite provided with the compiler. For example, the WIDECHAR is limited by its 16-bit size to only a portion of the unicode character set (the basic multi lingual plane), whereas a unicode character is 20-bits, and we would need either a 24-bit or 32-bit sized type to contain it all. ** Are there any other known limitations of the compiler, or library suite? - length of identifier? - length of TEXT (ie, memory) - length of filenames, or pathname (some architectures may have differences, ie MS-Windows). o There should be a discussion of the @m3XXX runtime library command line options. o There should be an EXAMPLE section, with example source code (Hello world), along with supporting m3makefile. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Wed Dec 2 18:36:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Dec 2009 18:36:34 +0100 Subject: [M3devel] [Modula-3] Draft press release In-Reply-To: <864527.8311.qm@web56803.mail.re3.yahoo.com> References: <864527.8311.qm@web56803.mail.re3.yahoo.com> Message-ID: <20091202183634.nua52s60gssw4s08@mail.elegosoft.com> Quoting Peter Eiserloh : > Hi Olaf, > > I began working on writing a press release for the impending > official release. Would you either suggest any changes, or > simply take it and run with it. It's great that somebody starts to work on advertising! We should wait for the final release before publishing an official press notice though. As there have been many changes to threading again in the release branch, there should at least be an RC5 (which may then become the `official' release). Browsing your text, I don't see any mention of the threading improvements (system based threads default on almost all platforms --> better scaling on multi-processors, improved M3 user threads code) and garbage collection work. Perhaps we could insert some quotes from Antony? You may want to add more changes from the list at http://www.opencm3.net/releng/relnotes-5.8-RC4.html, though not every detail needs to be listed in the press release. cm3ide comes to mind, as well as m3gdb, improved Windows support, and REFANY extensions. > BTW: I went to the download page to download a copy of > the source for version 5.5, but only found binaries for > selected architectures. The sources are there, but `Sources' was missing in the heading. It's the first archive listed. > Also, that section was listed as > "Current Development Snapshots: CM3 d5.5.0". Do we really > want to say "Current"? No. I've removed several `current's :-) > *** BEGIN CUT *** > CM3 V5.8 PRESS RELEASE > > The CM3 software development team is pleased to announce > the release of CM3 version 5.8.4, is now available for > download from > > http://www.opencm3.net/download.html > > CM3 is an open source Modula-3 compiler, descended from the > Critical Mass Modula-3 compiler, which itself came from > Digital Equipment Corp (DEC) Systems Research Center (SRC)'s > m3 compiler. > > This is the first release of the 5.8 branch. It contains > many enhancements over the previous official release (5.5), > including (but not limited by): > > * Language enhancements: > o New primitive type > - LONGINT o Minimal tagged REFANY values > > * New supported architectures: > o AMD64_LINUX > o PPC_DARWIN This is not new, but I386_OPENBSD and AMD64_FREEBSD are. I'm not sure what will finally be available though. > o X86_DARWIN > o etc ... > > * Compiler Improvements > o Rebased on top of GCC-4.1 I think that should be 4.3. > o Additional information provided with version > information. > o Support configuration scripts (in quake) reworked > for more commonality between architectures. Runtime Improvements: o system-based threading default on most target platforms allowing better scaling on multi-processors o many enhancements to the garbage collector o optional alternative TEXT implementation which promises better performance o restructured low-level code avoiding redundancies, making new ports easier to create and maintain > * Additional software suites: o CM3-IDE, the open source release of Critical Mass' Reactor (tm) product > o Caltech-parser > o Cvsup. > > * Miscellaneous: > o documentation: > - Manual pages for (cm3, quake, m3makefile, ...). o much improved debugging with m3gdb > Some selected historical improvements of CM3 over the > original DEC-SRC m3 compiler are: > > * Language enhancements: > o New primitive type > - WIDECHAR, and new widechar literal > o New pragmas: > - ASSERT, > - DEBUG, > - IMPLICIT. > > * Text may contain Unicode characters, > * Support for dynamically linked (shared) libraries. > > * The quake supporting scripting language is now embedded > within the compiler itself. > > We hope everyone tries this latest version of our Modula-3 compiler, > and associated library suite. > > The CM3 Modula-3 development team. > *** END CUT *** > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ Probably I've missed something; others may check and extend the list. 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 From rcoleburn at scires.com Wed Dec 2 23:17:55 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Dec 2009 17:17:55 -0500 Subject: [M3devel] threads are broken on Windows Message-ID: <4B16A059.1E75.00D7.1@scires.com> Something is wrong with threads on Windows from the HEAD branch. After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 2 23:21:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Dec 2009 17:21:49 -0500 Subject: [M3devel] threads are broken on Windows In-Reply-To: <4B16A059.1E75.00D7.1@scires.com> References: <4B16A059.1E75.00D7.1@scires.com> Message-ID: <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> Jay's call on that one... On 2 Dec 2009, at 17:17, Randy Coleburn wrote: > Something is wrong with threads on Windows from the HEAD branch. > > After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 > *** > > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 > 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 > 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 > 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 > 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 > 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 > 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Dec 2 23:47:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Dec 2009 17:47:37 -0500 Subject: [M3devel] Looking to update cm3 manual page. In-Reply-To: <538131.35719.qm@web56806.mail.re3.yahoo.com> References: <538131.35719.qm@web56806.mail.re3.yahoo.com> Message-ID: <4B16A74F.1E75.00D7.1@scires.com> Peter: We need to make sure to add information about cm3IDE. The users guide can be found at: m3-sys\cm3ide\UsersGuide\CM3_IDE_UsersGuide.pdf Some of the environment variables you describe have to do with cm3IDE. Here is a list: CM3_IDE_HOME = env var for root of home folder HOME = alternate home folder root, if CM3_IDE_HOME not supplied The following variables are expected to be defined in the CM3.CFG file: INITIAL_CM3_IDE_BROWSER = full path to the web browser that should be used with cm3IDE INITIAL_CM3_IDE_EDITOR = full path to the text editor that should be called by cm3IDE BUILD_DIR = NT386, HPPA, etc. PKG_USE = full path to the public package root, e.g. /cm3/pkg DOC_INSTALL = full path to the documentation root, e.g. /cm3/doc If the first 2 are not defined, cm3IDE will prompt user on command line to provide these the first time it is run. Thereafter, it saves the information in its config file that it places in the CM3_IDE_HOME folder. If the last 3 are not defined, cm3IDE tries to construct them using heuristics. If not successful, the program will abort. cm3IDE requires that is "examples" folder be located off the installation root, e.g., cm3/examples. If examples is not found, cm3IDE will still run, but it will not be able to offer up any examples. In an environment that allows spaces in filenames, such as Windows, you can run into problems if any of the paths defined in these variables have embedded spaces. On Windows, you can get around this problem by using the short 8.3 name equivalent. Regards, Randy >>> Peter Eiserloh 12/2/2009 12:01 PM >>> Hi all, It has been more than half a year since I last looked at the CM3 manual page. I am now looking at the it in preparation for the release of version 5.8, and noticing some deficiencies. I asking for help in identifying any further places it is lacking. I can integrate any feedback into a revised manual page, and submit an updated version back to the archives. Currently identified deficiencies: o The manual page should explicitly state which version of the compiler it documents. o The sub-section "Expected Directory Structure" needs a better discussion, especially an introduction. o The discussion of mode option "-ship" mentions environment variable CM3_INSTALL_ROOT, yet in cm3.cfg we set INSTALL_ROOT without the "CM3_" prefix. This should be resolved. ** What is the exact meaning of these two? Is one recognized by the compiler, and the other by the supporting quake code? o The ENVIRONMENT section does not mention CM3_INSTALL_ROOT at all. Add a discussion about both INSTALL_ROOT, and CM3_INSTALL_ROOT. ** Am I missing any other environment variables? o Missing command line options for the compiler: - I currently have "-g", but no discussion of -gstabs. No discussion about not supporting DWARF (or do we?). o Compiler unique language features, (i.e., pragmas). The reference books (Nelson, and Harbison) give a list of suggested pragmas. The manual page should list the ones supported by the CM3 compiler explicitly, and show their syntax. ** Can someone list for me the pragmas supported by the current (5.8.4) compiler. o Should list any limitations of either the compiler, or the library suite provided with the compiler. For example, the WIDECHAR is limited by its 16-bit size to only a portion of the unicode character set (the basic multi lingual plane), whereas a unicode character is 20-bits, and we would need either a 24-bit or 32-bit sized type to contain it all. ** Are there any other known limitations of the compiler, or library suite? - length of identifier? - length of TEXT (ie, memory) - length of filenames, or pathname (some architectures may have differences, ie MS-Windows). o There should be a discussion of the @m3XXX runtime library command line options. o There should be an EXAMPLE section, with example source code (Hello world), along with supporting m3makefile. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 01:18:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 00:18:20 +0000 Subject: [M3devel] threads are broken on Windows In-Reply-To: <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> References: <4B16A059.1E75.00D7.1@scires.com>, <24C8B5F0-D051-450A-93DE-F0ED0B76F162@cs.purdue.edu> Message-ID: That's wierd, but I do see it occuring too. Will look later. - Jay From: hosking at cs.purdue.edu Date: Wed, 2 Dec 2009 17:21:49 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] threads are broken on Windows Jay's call on that one... On 2 Dec 2009, at 17:17, Randy Coleburn wrote: Something is wrong with threads on Windows from the HEAD branch. After checking out HEAD and rebuilding everything, cm3IDE crashes with the following message: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 768 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2e0fcec 0x4f420d ProcessStacks + 0x80 in ..\src\thread\WIN32\ThreadWin32.m3 0x2e0fd40 0x4fbee0 CollectSomeInStateZero + 0x304 in ..\src\runtime\common\RTCollector.m3 0x2e0fd54 0x4fbba0 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x2e0fd98 0x4fb837 CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3 0x2e0fdd8 0x4f73bc AllocTraced + 0xd7 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe0c 0x4f69d3 GetTracedObj + 0x8c in ..\src\runtime\common\RTAllocator.m3 0x2e0fe30 0x4f64cd AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3 0x2e0fe58 0x4547a9 New + 0x19 in ..\src\misc\LineWr.m3 0x2e0ff20 0x45328a DoBrowse + 0x41 in ..\src\misc\Display.m3 0x2e0ff60 0x4f34b5 RunThread + 0x189 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 12:09:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 11:09:53 +0000 Subject: [M3devel] processing stack/context Message-ID: Tony, it looks like you assume the context passed to a signal handler is on the stack. Is that really guaranteed? It couldn't be in some thread local for some reason? (signals can nest? Therefore that would be problematic?) We can just use the address of a local, right? And we can assume the signal stack is the regular stack? By default? (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 3 16:05:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Dec 2009 10:05:33 -0500 Subject: [M3devel] processing stack/context In-Reply-To: References: Message-ID: <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Actually, in the latest version I explicitly process the signal context as well as the stack. On 3 Dec 2009, at 06:09, Jay K wrote: > Tony, it looks like you assume the context passed to a signal handler is on the stack. > Is that really guaranteed? It couldn't be in some thread local for some reason? > (signals can nest? Therefore that would be problematic?) > We can just use the address of a local, right? > > And we can assume the signal stack is the regular stack? > By default? > (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) > > I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 19:33:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 18:33:03 +0000 Subject: [M3devel] processing stack/context In-Reply-To: <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> References: , <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Message-ID: Tony, Understood, but you use the context as one end of the stack. void ThreadPThread__ProcessStopped (m3_pthread_t mt, char *bottom, char *context, void (*p)(void *start, void *limit)) { /* process stack */ if (stack_grows_down) { assert(context < bottom); p(context, bottom); here } else { assert(bottom < context); p(bottom, context); here } /* process register context */ p(context, context + sizeof(ucontext_t)); } - Jay From: hosking at cs.purdue.edu Date: Thu, 3 Dec 2009 10:05:33 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] processing stack/context Actually, in the latest version I explicitly process the signal context as well as the stack. On 3 Dec 2009, at 06:09, Jay K wrote: Tony, it looks like you assume the context passed to a signal handler is on the stack. Is that really guaranteed? It couldn't be in some thread local for some reason? (signals can nest? Therefore that would be problematic?) We can just use the address of a local, right? And we can assume the signal stack is the regular stack? By default? (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 3 20:02:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Dec 2009 14:02:34 -0500 Subject: [M3devel] processing stack/context In-Reply-To: References: , <402DACEC-E2B3-4CDD-85F4-487519055D5A@cs.purdue.edu> Message-ID: <9C163B67-026B-48CD-B6D0-1C54D7910166@cs.purdue.edu> Ah, yes, understood. I think in general one can assume that the signal handler context is on the actual stack (we are not using sigaltstack here), but yes it might be safer to explicitly extract a "top" value in the signal handler, independently of the context and pass it in as another parameter to ProcessStopped. 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 3 Dec 2009, at 13:33, Jay K wrote: > Tony, Understood, but you use the context as one end of the stack. > > void > ThreadPThread__ProcessStopped (m3_pthread_t mt, char *bottom, char *context, > void (*p)(void *start, void *limit)) > { > /* process stack */ > if (stack_grows_down) { > assert(context < bottom); > p(context, bottom); here > } else { > assert(bottom < context); > p(bottom, context); here > } > /* process register context */ > p(context, context + sizeof(ucontext_t)); > } > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 3 Dec 2009 10:05:33 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] processing stack/context > > Actually, in the latest version I explicitly process the signal context as well as the stack. > > On 3 Dec 2009, at 06:09, Jay K wrote: > > Tony, it looks like you assume the context passed to a signal handler is on the stack. > Is that really guaranteed? It couldn't be in some thread local for some reason? > (signals can nest? Therefore that would be problematic?) > We can just use the address of a local, right? > > And we can assume the signal stack is the regular stack? > By default? > (I know sigstack/sigaltstack can fiddle with it; we should assume it isn't used.) > > I noticed this in structure ThreadWin32.m3 a bit more like ThreadPosix.m3. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 3 22:20:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Dec 2009 21:20:32 +0000 Subject: [M3devel] ThreadWin32/LockMutex/giantLock/alertable? Message-ID: It'd be good to remove the giantLock from LockMutex/UnlockMutex. Mutexes can be replaced, like in Java, with just interlocked+semaphore -- no wait list (the semaphore would have an implicit wait list) -- or similarly just a Win32 critical section. I believe the inefficieny of ThreadWin32 having a "giantLock" need not impact folks only using locks -- it is only needed when acting on condition variables, and /possibly/ alert/alertwait (but probably not). In looking at it, something that bugs me is "act.alertable := FALSE". That can be outside the lock? Or remove entirely? And/or moved to before "RAISE Alerted"? Or for that matter, AlertWait should always exit with it false? And Wait should always assert it true? And there's some redundancy there. Basically, it should always be FALSE unless within AlertWait? I'm pretty sure those later options -- alertable is generally false, and writes only need to occur within AlertWait to make it temporarily true. LockMutex could just assert that it is false. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 10:00:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 09:00:27 +0000 Subject: [M3devel] FW: some open bugs In-Reply-To: <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 12:48:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 11:48:46 +0000 Subject: [M3devel] DateBsd.m3 lock usually not needed Message-ID: It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:06:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:06:45 +0000 Subject: [M3devel] some open bugs In-Reply-To: <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: In head: https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) doesn't occur jbook2:bin jay$ /cm3.amd64/bin/cm3 ? --- building in AMD64_DARWIN --- Fatal Error: unsupported file type "?" Perhaps should print usage. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Mixed. https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between doesn't occur There is this: m3-sys/windowsResources/AMD64_DARWIN/.M3SHIP seems to be broken: make_dir("/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib") symbolic_link_file("libwindowsResources.5.2.dylib", "/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib/libwindowsResources.dylib") symbolic_link_file("libwindowsResources.5.2.dylib", "/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-//cm3/bin/../lib/libwindowsResources.5.dylib") Which I understand in general, haven't looked at it here. I'm not too blame for all the funny characters in "tmp". Apple does that. Need to test release. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: FW: some open bugs Date: Sun, 6 Dec 2009 09:00:27 +0000 > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:18:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:18:39 +0000 Subject: [M3devel] formsedit AMD64_DARWIN unslotted thread Message-ID: Tony, somtimes, like one in ten, starting up, AMD64_DARWIN, formsedit, head. Maybe worth trying a simpler AssignSlot? (gdb) r Starting program: /private/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-/cm3/bin/formsedit warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries +++++++++++++++++..... done *** *** runtime error: *** Thread client error: unslotted thread! *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 349 *** Program received signal SIGABRT, Aborted. 0x00007fff83416e3e in semaphore_wait_signal_trap () (gdb) thread apply all bt Thread 8 (process 54920 thread 0x2693): #0 0x00007fff834e06be in __semwait_signal_nocancel () #1 0x00007fff834e02f4 in nanosleep$NOCANCEL () #2 0x00007fff834da404 in usleep$NOCANCEL () #3 0x00007fff834eef77 in abort () #4 0x00000001009acbe1 in Cstdlib__abort () #5 0x00000001009a2eea in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #6 0x0000000100996e64 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #7 0x000000010099457d in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #8 0x0000000100994229 in RTError__Msg (M3_Bd56fi_file=0x1009f5fb0, M3_AcxOUs_line=349, M3_Bd56fi_msgA=0x1009f5ff0, M3_Bd56fi_msgB=0x1009f5b88, M3_Bd56fi_msgC=0x0) at ../src/runtime/common/RTError.m3:23 #9 0x00000001009a97fe in ThreadPThread__Die (M3_AcxOUs_lineno=349, M3_Bd56fi_msg=0x1009f5b88) at ../src/thread/PTHREAD/ThreadPThread.m3:1245 #10 0x00000001009a5fe1 in ThreadPThread__FreeSlot (M3_BXP32l_t=0x102259910) at ../src/thread/PTHREAD/ThreadPThread.m3:349 #11 0x00000001009a6b1c in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101635220) at ../src/thread/PTHREAD/ThreadPThread.m3:486 #12 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101635220) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #13 0x00007fff83444e8b in _pthread_start () #14 0x00007fff83444d4d in thread_start () Thread 7 (process 54920 thread 0x2707): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x10162c590, M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257210, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257210) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x00000001003b17fa in XMessenger__Messenger (M3_EVlqQO_self=0x1015d23a8) at ../src/xvbt/XMessenger.m3:69 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c590) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c590) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 6 (process 54920 thread 0x240b): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x10162c480, M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257250, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x102256b38, M3_Bl0jv4_c=0x102257250) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x00000001003c1167 in XInput__FilterXInput (M3_DSd60P_self=0x1015d2330) at ../src/xvbt/XInput.m3:102 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c480) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c480) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 5 (process 54920 thread 0x250b): #0 0x00007fff83462582 in select$DARWIN_EXTSN () #1 0x00000001009ab82d in Unix__select () #2 0x00000001009a7e88 in ThreadPThread__XIOWait__CallSelect.1153 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:677 #3 0x00000001009a7b20 in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:716 #4 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:619 #5 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x1015d22b8) at ../src/xvbt/XInput.m3:63 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 4 (process 54920 thread 0x2103): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5ef in ThreadPThread__pthread_cond_timedwait () #3 0x00000001009a72d9 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1016185f0, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:575 #4 0x00000001009a73b5 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:590 #5 0x0000000100075ab2 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:259 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 3 (process 54920 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4f16 in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a503b in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 54920 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5ef in ThreadPThread__pthread_cond_timedwait () #3 0x00000001009a72d9 in ThreadPThread__XPause (M3_DMxDjQ_self=0x101618080, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:575 #4 0x00000001009a73b5 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:590 #5 0x00000001004090cf in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:460 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:471 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:445 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 54920 local thread 0x2e03): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a570d in ThreadPThread__AssignSlot (M3_BXP32l_t=0x1021cc0b0) at ../src/thread/PTHREAD/ThreadPThread.m3:301 #4 0x00000001009a6516 in ThreadPThread__CreateT (M3_DMxDjQ_act=0x1016353b0) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #5 0x00000001009a6b72 in Thread__Fork (M3_EMTrVz_closure=0x1015b1990) at ../src/thread/PTHREAD/ThreadPThread.m3:496 #6 0x000000010040a402 in VBTRep__Mark (M3_BFdKo9_v=0x1021fe380) at ../src/vbt/VBTRep.m3:587 #7 0x00000001003fcedf in VBT__Mark (M3_BFdKo9_v=0x1021fe380) at ../src/vbt/VBT.m3:1247 #8 0x000000010042ee00 in HVSplit__NewShape (M3_ABI5Rn_v=0x1021fe380, M3_BFdKo9_ch=0x1022002d8) at ../src/split/HVSplit.m3:487 #9 0x00000001003fcbd3 in VBT__NewShape (M3_BFdKo9_v=0x1022002d8) at ../src/vbt/VBT.m3:1225 #10 0x000000010007d2ad in FlexVBT__Rescreen (M3_BpJoz9_v=0x1022002d8, M3_BpW0LT_cd=0x7fff5fbfc800) at ../src/lego/FlexVBT.m3:101 #11 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1022002d8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #12 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fe380, M3_BpW0LT_cd=0x7fff5fbfc990) at ../src/vbt/VBTClass.m3:751 #13 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fe380, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #14 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fcbb8, M3_BpW0LT_cd=0x7fff5fbfcb20) at ../src/vbt/VBTClass.m3:751 #15 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fcbb8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #16 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fc018, M3_BpW0LT_cd=0x7fff5fbfcd20) at ../src/vbt/VBTClass.m3:751 #17 0x0000000100429b6d in BorderedVBT__Rescreen (M3_C4s4Wp_v=0x1021fc018, M3_BpW0LT_cd=0x7fff5fbfcd20) at ../src/split/BorderedVBT.m3:157 #18 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fc018, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #19 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb4e8, M3_BpW0LT_cd=0x7fff5fbfcee0) at ../src/vbt/VBTClass.m3:751 #20 0x000000010007d2a4 in FlexVBT__Rescreen (M3_BpJoz9_v=0x1021fb4e8, M3_BpW0LT_cd=0x7fff5fbfcee0) at ../src/lego/FlexVBT.m3:100 #21 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb4e8, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #22 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa248, M3_BpW0LT_cd=0x7fff5fbfd070) at ../src/vbt/VBTClass.m3:751 #23 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa248, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #24 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb410, M3_BpW0LT_cd=0x7fff5fbfd230) at ../src/vbt/VBTClass.m3:751 #25 0x00000001000a675f in ShadowedVBT__Rescreen (M3_AyFi3t_v=0x1021fb410, M3_BpW0LT_cd=0x7fff5fbfd230) at ../src/lego/ShadowedVBT.m3:86 #26 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb410, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #27 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fbe00, M3_BpW0LT_cd=0x7fff5fbfd3c0) at ../src/vbt/VBTClass.m3:751 #28 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fbe00, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #29 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fb330, M3_BpW0LT_cd=0x7fff5fbfd5c0) at ../src/vbt/VBTClass.m3:751 #30 0x0000000100429b6d in BorderedVBT__Rescreen (M3_C4s4Wp_v=0x1021fb330, M3_BpW0LT_cd=0x7fff5fbfd5c0) at ../src/split/BorderedVBT.m3:157 #31 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fb330, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #32 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa160, M3_BpW0LT_cd=0x7fff5fbfd810) at ../src/vbt/VBTClass.m3:751 #33 0x0000000100451530 in StableVBT__Rescreen (M3_CStG2l_w=0x1021fa160, M3_BpW0LT_cd=0x7fff5fbfd810) at ../src/split/StableVBT.m3:115 #34 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa160, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #35 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021fa018, M3_BpW0LT_cd=0x7fff5fbfda00) at ../src/vbt/VBTClass.m3:751 #36 0x00000001000b2711 in ZChildVBT__Rescreen (M3_EF20wQ_v=0x1021fa018, M3_BpW0LT_cd=0x7fff5fbfda00) at ../src/lego/ZChildVBT.m3:127 #37 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021fa018, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #38 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1015aea90, M3_BpW0LT_cd=0x7fff5fbfdc10) at ../src/vbt/VBTClass.m3:751 #39 0x0000000100432804 in ZSplit__Rescreen (M3_COSw3M_v=0x1015aea90, M3_BpW0LT_cd=0x7fff5fbfdc10) at ../src/split/ZSplit.m3:235 #40 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1015aea90, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #41 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8970, M3_BpW0LT_cd=0x7fff5fbfddd0) at ../src/vbt/VBTClass.m3:751 #42 0x000000010007d2a4 in FlexVBT__Rescreen (M3_BpJoz9_v=0x1021f8970, M3_BpW0LT_cd=0x7fff5fbfddd0) at ../src/lego/FlexVBT.m3:100 #43 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8970, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #44 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8858, M3_BpW0LT_cd=0x7fff5fbfdf60) at ../src/vbt/VBTClass.m3:751 #45 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8858, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #46 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1021f8770, M3_BpW0LT_cd=0x7fff5fbfe0f0) at ../src/vbt/VBTClass.m3:751 #47 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1021f8770, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #48 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x101799158, M3_BpW0LT_cd=0x7fff5fbfe300) at ../src/vbt/VBTClass.m3:751 #49 0x0000000100432804 in ZSplit__Rescreen (M3_COSw3M_v=0x101799158, M3_BpW0LT_cd=0x7fff5fbfe300) at ../src/split/ZSplit.m3:235 #50 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x101799158, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #51 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1015b7918, M3_BpW0LT_cd=0x7fff5fbfe490) at ../src/vbt/VBTClass.m3:751 #52 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1015b7918, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #53 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b9858, M3_BpW0LT_cd=0x7fff5fbfe650) at ../src/vbt/VBTClass.m3:751 #54 0x0000000100469d11 in InstalledVBT__Rescreen (M3_BnDICA_v=0x1024b9858, M3_BpW0LT_cd=0x7fff5fbfe650) at ../src/trestle/InstalledVBT.m3:77 #55 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b9858, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #56 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b9948, M3_BpW0LT_cd=0x7fff5fbfe8a0) at ../src/vbt/VBTClass.m3:751 #57 0x0000000100451530 in StableVBT__Rescreen (M3_CStG2l_w=0x1024b9948, M3_BpW0LT_cd=0x7fff5fbfe8a0) at ../src/split/StableVBT.m3:115 #58 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b9948, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #59 0x00000001004048bd in VBTClass__RescreenDefault (M3_Dg4CVT_v=0x1024b97a0, M3_BpW0LT_cd=0x7fff5fbfea80) at ../src/vbt/VBTClass.m3:751 #60 0x000000010045342f in JoinedVBT__Rescreen (M3_B2daE0_v=0x1024b97a0, M3_BpW0LT_cd=0x7fff5fbfea80) at ../src/split/JoinedVBT.m3:169 #61 0x00000001003ffbca in VBTClass__Rescreen (M3_BFdKo9_v=0x1024b97a0, M3_BFpUSj_st=0x1024a0b30) at ../src/vbt/VBTClass.m3:186 #62 0x0000000100457e68 in JoinParent__Be (M3_EjiMte_prntP=0x1024a08d0, M3_B2daE0_v=0x1024b97a0) at ../src/split/JoinParent.m3:309 #63 0x0000000100467485 in DpyFilter__Init (M3_AMerq9_v=0x1024a08d0, M3_B2daE0_ch=0x1024b97a0, M3_AicXUJ_enabled=1 '\001') at ../src/trestle/DpyFilter.m3:59 #64 0x00000001004699e1 in InstalledVBT__InitParent (M3_DaeRwb_res=0x1024a08d0, M3_Bli4Mk_ch=0x1024b97a0) at ../src/trestle/InstalledVBT.m3:49 #65 0x000000010046cee9 in Trestle__AddApp (M3_D5sYfW_a=0x1024a0878, M3_Arkhkf_cuser=0x1015d2460) at ../src/trestle/Trestle.m3:402 #66 0x000000010046c1a9 in Trestle__NoConfInit (M3_D5sYfW_a=0x1024a0878, M3_Arkhkf_u=0x1015d2460) at ../src/trestle/Trestle.m3:317 #67 0x000000010046caf1 in Trestle__InnerAttach (M3_BFdKo9_v=0x1015b7918, M3_DpX0S5_trsl=0x102256b38) at ../src/trestle/Trestle.m3:379 #68 0x000000010046c17b in Trestle__Attach (M3_BFdKo9_v=0x1015b7918, M3_DpX0S5_trsl=0x102256b38) at ../src/trestle/Trestle.m3:285 #69 0x0000000100008c58 in FormsEditVBT__Install (M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_editorGeo=0x100163230) at ../src/FormsEditVBT.m3:379 #70 0x0000000100007371 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:255 #71 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #72 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #73 0x000000010099385e in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #74 0x0000000100992ba2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #75 0x0000000100992c40 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #76 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff858, envp=0x7fff5fbff868) at _m3main.mc:4 (gdb) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 15:25:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 09:25:58 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: Message-ID: That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... 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 6 Dec 2009, at 06:48, Jay K wrote: > It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:29:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:29:29 +0000 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: , Message-ID: I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while switching is disabled? I came up with something a bit hacky but maybe ok. - Jay Subject: Re: [M3devel] DateBsd.m3 lock usually not needed From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 09:25:58 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... 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 On 6 Dec 2009, at 06:48, Jay K wrote:It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:31:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:31:13 +0000 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up Message-ID: formsedit startup seems to often hang in the debugger, in head. The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) (gdb) thread apply all bt Thread 7 (process 56120 thread 0x250b): #0 0x00007fffffe0027d in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 6 (process 56120 thread 0x240b): #0 0x00007fffffe00278 in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 5 (process 56120 thread 0x2707): #0 0x00007fffffe00296 in ?? () #1 0x00007fff83447ec2 in _pthread_lookup_thread () #2 0x00007fff83447e73 in pthread_mach_thread_np () #3 0x00000001009aa770 in ThreadPThread__SuspendThread () #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #18 0x00007fff83444e8b in _pthread_start () #19 0x00007fff83444d4d in thread_start () Thread 4 (process 56120 thread 0x2103): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #9 0x00007fff83444e8b in _pthread_start () #10 0x00007fff83444d4d in thread_start () Thread 3 (process 56120 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 56120 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 56120 local thread 0x2e03): #0 0x00007fff83444c48 in pthread_create () #1 0x00000001009aa2eb in ThreadPThread__thread_create () #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 (gdb) cont Continuing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 6 15:37:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Dec 2009 15:37:00 +0100 Subject: [M3devel] Hudson failures and outages, was: RE: solsun/solgnu In-Reply-To: References: , <20091129175131.3a9yckela8cgck0c@mail.elegosoft.com> Message-ID: <20091206153700.m98zvhh3dwwo04go@mail.elegosoft.com> Quoting Jay K : > There was also a problem with SOLgnu where a bad cm3 had been built > and gotten "stuck". > I cleaned up the various directories in the workspace and got it > working again. > (There's no evidence trail.) Great, thanks. I've had a more or less complete server crash here at home and had to get a new machine. I'm still busy reinstalling and recovering. Unfortunately, this is now also the step from 32 to 64 bits for my server, and most of the old programs/setups don't work out of the box. I'll probably need several more days until everything is in working order again. So luthien will probably not be available for FreeBSD4 builds. The good news is that I can now test the AMD64_FREEBSD stuff :-) 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 From jay.krell at cornell.edu Sun Dec 6 15:48:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:48:22 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head Message-ID: Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 6 15:51:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Dec 2009 14:51:34 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: Message-ID: I also saw I386_DARWIN Juno FreeSlot: z=0x2141c94 t=0xb038ced0 n_slotted=7 slots=0xb7909c t.act=0x22b8010 t.act.slot=14 *** *** runtime error: *** Thread client error: unslotted thread! *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 364 *** What I'll probably do over the next few days is test more PPC_DARWIN, LINUXLIBC6, Solaris, maybe some BSD, see where it occurs. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 6 Dec 2009 14:48:22 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:14:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:14:14 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: References: , Message-ID: <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> On 6 Dec 2009, at 09:29, Jay K wrote: > I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while > switching is disabled? Yes, it sure can. DisableSwitching/EnableSwitching is exactly what is needed whenever you are dealing with libraries that are not thread safe with the user-level thread-switching. > I came up with something a bit hacky but maybe ok. > > - Jay > > > Subject: Re: [M3devel] DateBsd.m3 lock usually not needed > From: hosking at cs.purdue.edu > Date: Sun, 6 Dec 2009 09:25:58 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... > > 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 6 Dec 2009, at 06:48, Jay K wrote: > > It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:16:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:16:51 -0500 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up In-Reply-To: References: Message-ID: Maybe related to the FreeSlot problem I just fixed? Please try with the latest. On 6 Dec 2009, at 09:31, Jay K wrote: > formsedit startup seems to often hang in the debugger, in head. > > The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. > I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) > > (gdb) thread apply all bt > > Thread 7 (process 56120 thread 0x250b): > #0 0x00007fffffe0027d in ?? () > #1 0x00007fff83444db7 in _pthread_start () > #2 0x00007fff83444d4d in thread_start () > > Thread 6 (process 56120 thread 0x240b): > #0 0x00007fffffe00278 in ?? () > #1 0x00007fff83444db7 in _pthread_start () > #2 0x00007fff83444d4d in thread_start () > > Thread 5 (process 56120 thread 0x2707): > #0 0x00007fffffe00296 in ?? () > #1 0x00007fff83447ec2 in _pthread_lookup_thread () > #2 0x00007fff83447e73 in pthread_mach_thread_np () > #3 0x00000001009aa770 in ThreadPThread__SuspendThread () > #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 > #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 > #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 > #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 > #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 > #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 > #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 > #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 > #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 > #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 > #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 > #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 > #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #18 0x00007fff83444e8b in _pthread_start () > #19 0x00007fff83444d4d in thread_start () > > Thread 4 (process 56120 thread 0x2103): > #0 0x00007fff83416e3e in semaphore_wait_signal_trap () > #1 0x00007fff8341e758 in pthread_mutex_lock () > #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () > #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 > #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 > #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 > #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 > #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #9 0x00007fff83444e8b in _pthread_start () > #10 0x00007fff83444d4d in thread_start () > > Thread 3 (process 56120 thread 0x2003): > #0 0x00007fff8341ddc2 in __semwait_signal () > #1 0x00007fff83445ca9 in _pthread_cond_wait () > #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () > #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 > #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #8 0x00007fff83444e8b in _pthread_start () > #9 0x00007fff83444d4d in thread_start () > > Thread 2 (process 56120 thread 0x313): > #0 0x00007fff8341ddc2 in __semwait_signal () > #1 0x00007fff83445ca9 in _pthread_cond_wait () > #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () > #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 > #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 > #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 > #8 0x00007fff83444e8b in _pthread_start () > #9 0x00007fff83444d4d in thread_start () > > Thread 1 (process 56120 local thread 0x2e03): > #0 0x00007fff83444c48 in pthread_create () > #1 0x00000001009aa2eb in ThreadPThread__thread_create () > #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 > #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 > #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 > #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 > #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 > #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 > #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 > #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 > #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 > #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 > #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 > #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 > #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 > #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 > (gdb) cont > Continuing. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 6 20:23:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Dec 2009 14:23:33 -0500 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: Message-ID: Please report back how things behave with the latest commit... On 6 Dec 2009, at 09:48, Jay K wrote: > Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). > > Here is the second crash > > (gdb) r > Starting program: /Users/jay/cm3/bin/Juno > Reading symbols for shared libraries +++++++++++++++++++++++..... done > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 > [Switching to process 79884 thread 0x29b7] > 0x01710774 in ?? () > (gdb) bt > #0 0x01710774 in ?? () > #1 0xb038cf28 in ?? () > Previous frame inner to this frame (gdb could not unwind past this frame) > (g > > > (gdb) thread apply all bt > > Thread 9 (process 79884 thread 0x27bf): > #0 0x968782ce in semaphore_wait_signal_trap () > #1 0x9687fda5 in pthread_mutex_lock () > #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () > #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 > #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 > #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 > #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #7 0x968a9155 in _pthread_start () > #8 0x968a9012 in thread_start () > > Thread 8 (process 79884 thread 0x29b7): > #0 0x01710774 in ?? () > #1 0xb038cf28 in ?? () > Previous frame inner to this frame (gdb could not unwind past this frame) > > Thread 7 (process 79884 thread 0x2603): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 6 (process 79884 thread 0x2507): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 5 (process 79884 thread 0x240f): > #0 0x968c76fa in select$DARWIN_EXTSN () > #1 0x00b524c3 in Unix__select () > #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 > #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 > #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 > #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 > #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #8 0x968a9155 in _pthread_start () > #9 0x968a9012 in thread_start () > > Thread 4 (process 79884 thread 0x2303): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () > #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () > #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 > #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 > #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 3 (process 79884 thread 0x2203): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () > #3 0x00b51431 in ThreadPThread__pthread_cond_wait () > #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 > #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 > #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 2 (process 79884 thread 0x1003): > #0 0x9687f46e in __semwait_signal () > #1 0x968aa3e6 in _pthread_cond_wait () > #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () > #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () > #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 > #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 > #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 > #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 > #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 > #9 0x968a9155 in _pthread_start () > #10 0x968a9012 in thread_start () > > Thread 1 (process 79884 local thread 0x2e03): > #0 0x968782ce in semaphore_wait_signal_trap () > #1 0x9687fda5 in pthread_mutex_lock () > #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () > #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 > #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 > #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 > #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 > #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 > #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 > #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 > #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 > #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 > #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 > #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 > #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 > #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:54:46 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:54:46 -0500 Subject: [M3devel] FW: some open bugs In-Reply-To: References: , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com> Message-ID: <4B1C34ED.1E75.00D7.1@scires.com> Hi Jay: Can you be more specific about the nature of the "windows C runtime version issue" you report below ? Regards, Randy >>> Jay K 12/6/2009 4:00 AM >>> > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue This is Windows specific. There are tricky issues here. I suggest for this we build multiple releases, one per C runtime version. Probably 2005 and 2008. That is probably the easiest solution. (I already suggested this and it is partly/fully in place?) I can try to look into it more, but building 2005 and 2008 should be easy enough. I can actually easily enough build a "release" for 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1 (2003), 8.0 (2005), 9.0 (2008) 10.0 is coming soon as well. But I think 2005 and 2008 will suit most people. We can also put up "boot" releases. I'd like to cut the C runtime dependency, it is already pretty light, but it hard to cut entirely, and that has issues for linking Modula-3 to C/C++. Maybe linking statically will be ok and work? https://projects.elego.de/cm3/ticket/1076 "cm3 ?" crashes (array access out of bounds) This is probably fixed. Certainly the command line parsing had been recently made crash prone and then improved. https://projects.elego.de/cm3/ticket/1068 32/64bit pickle issue. I've never used pickles at all. Needs investigation. https://projects.elego.de/cm3/ticket/1068 many GUI apps fail on AMD64_DARWIN. Somewhat old report, by me. We can cut this platform for this release if the bug persists. Lame. Needs investigation/confirmation. https://projects.elego.de/cm3/ticket/1048 libz problem on Solaris. fixed? https://projects.elego.de/cm3/ticket/1056 make-dist is confused on AMD64_DARWIN between AMD64 and I386. Not a big deal either way. Maybe fixed, or easy to fix, or cut the platform. (I don't think we have AMD64_DARWIN in Hudson/Tinderbox. My I386_DARWIN system can be it (on an alternate network at the moment).) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:57:02 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:57:02 -0500 Subject: [M3devel] build problem diagnosis in caltech-parser test package References: <4B150A90020000D700067FB8@scires.com> Message-ID: <4B1C3575.1E75.00D7.1@scires.com> I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 7 04:59:15 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 06 Dec 2009 22:59:15 -0500 Subject: [M3devel] Fwd: [M3commit] CVS Update: cm3 References: <20091201165512.EA71F2474001@birch.elegosoft.com> Message-ID: <4B1C35FA.1E75.00D7.1@scires.com> Is everyone ok with the edit I made here? If so, someone should promote this fix to the release branch. Also, Is there a reason we should limit this package to POSIX platforms? If not, we should take out the if statement at line 31 and the corresponding end. --Randy >>> Randy Coleburn 12/1/2009 5:55 PM >>> CVSROOT:/usr/cvs Changes by:rcoleburn at birch.09/12/01 17:55:12 Modified files: cm3/m3-tools/cvsup/suplib/src/: m3makefile Log message: add missing "end" statement at line 58 to correct compile-time syntax error. Someone needs to check me on this one. After this change, I don't get any packages built in cvsup on WindowsXP, I suppose due to some prerequiste not being met. But at least I don't get the syntax error. Not sure why the package m3makefile seems to be limited to POSIX platforms at line 31. Everything was building on Windows before.--R.Coleburn Here is the compiler output before my correction: C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES "C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args", line 5: quake runtime error: C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\src\m3makefile, line 263: syntax error: "end" or "else" expected after "if" --procedure-- -line- -file--- include_dir -- 5 C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.03 2 removing temporary files 0.03 other --------------------------------------------------- 0.06 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:44:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:44:02 +0000 Subject: [M3devel] AMD64_DARWIN head formsedit sometimes hangs starting up In-Reply-To: References: , Message-ID: Yes better now thank you. - Jay Subject: Re: AMD64_DARWIN head formsedit sometimes hangs starting up From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 14:16:51 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Maybe related to the FreeSlot problem I just fixed? Please try with the latest. On 6 Dec 2009, at 09:31, Jay K wrote:formsedit startup seems to often hang in the debugger, in head. The one obvious guess is that the thread trying to take the heap lock is waiting forever and not responding to the suspend. I should probably go back and test I386_DARWIN and PPC_DARWIN instead? (and release branch) (gdb) thread apply all bt Thread 7 (process 56120 thread 0x250b): #0 0x00007fffffe0027d in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 6 (process 56120 thread 0x240b): #0 0x00007fffffe00278 in ?? () #1 0x00007fff83444db7 in _pthread_start () #2 0x00007fff83444d4d in thread_start () Thread 5 (process 56120 thread 0x2707): #0 0x00007fffffe00296 in ?? () #1 0x00007fff83447ec2 in _pthread_lookup_thread () #2 0x00007fff83447e73 in pthread_mach_thread_np () #3 0x00000001009aa770 in ThreadPThread__SuspendThread () #4 0x00000001009a8db0 in ThreadPThread__StopThread (M3_DMxDjQ_act=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:1014 #5 0x00000001009a8f55 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1053 #6 0x00000001009a84d6 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:819 #7 0x0000000100988858 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #8 0x0000000100988804 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #9 0x0000000100988339 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #10 0x000000010097fa2c in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=24, M3_Cwb5VA_dataAlignment=8, M3_BSbHbM_thread=0x10162c3e8) at ../src/runtime/common/RTAllocator.m3:365 #11 0x000000010097f2ad in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:294 #12 0x000000010097e454 in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x1009e1ac8, M3_ANmeAM_s=0x102186b10) at ../src/runtime/common/RTAllocator.m3:141 #13 0x00000001009a779b in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x10162c370, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:657 #14 0x00000001009a752e in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:631 #15 0x00000001003c0dfa in XInput__WaitForXInput (M3_Bkyxhg_self=0x101787a30) at ../src/xvbt/XInput.m3:63 #16 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #17 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x10162c370) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #18 0x00007fff83444e8b in _pthread_start () #19 0x00007fff83444d4d in thread_start () Thread 4 (process 56120 thread 0x2103): #0 0x00007fff83416e3e in semaphore_wait_signal_trap () #1 0x00007fff8341e758 in pthread_mutex_lock () #2 0x00000001009aa6a3 in ThreadPThread__pthread_mutex_lock () #3 0x00000001009a9c39 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1355 #4 0x000000010098e408 in RTWeakRef__WeakRefToRef (M3_D9M1dT_t=0x102103d50) at ../src/runtime/common/RTCollector.m3:2108 #5 0x00000001009c4147 in WeakRef__ToRef (M3_ArcXsu_w={}) at ../src/weakref/WeakRef.m3:20 #6 0x0000000100075781 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1015e9170) at ../src/lego/FileBrowserVBT.m3:243 #7 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #8 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016185f0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #9 0x00007fff83444e8b in _pthread_start () #10 0x00007fff83444d4d in thread_start () Thread 3 (process 56120 thread 0x2003): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x1016184d0, M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b5d20, M3_Bl0jv4_c=0x1015b5d38) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x000000010010b258 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1015b5d58) at ../src/vtext/VTView.m3:111 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1016184d0) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 2 (process 56120 thread 0x313): #0 0x00007fff8341ddc2 in __semwait_signal () #1 0x00007fff83445ca9 in _pthread_cond_wait () #2 0x00000001009aa5c8 in ThreadPThread__pthread_cond_wait () #3 0x00000001009a4e8e in ThreadPThread__XWait (M3_DMxDjQ_self=0x101618080, M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #4 0x00000001009a4fb3 in Thread__Wait (M3_AYIbX3_m=0x1015b1940, M3_Bl0jv4_c=0x1015b1958) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #5 0x0000000100408cdc in VBTRep__MeterMaid (M3_EMTrVz_self=0x1015b19a8) at ../src/vbt/VBTRep.m3:439 #6 0x00000001009a6998 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:483 #7 0x00000001009a6642 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x101618080) at ../src/thread/PTHREAD/ThreadPThread.m3:457 #8 0x00007fff83444e8b in _pthread_start () #9 0x00007fff83444d4d in thread_start () Thread 1 (process 56120 local thread 0x2e03): #0 0x00007fff83444c48 in pthread_create () #1 0x00000001009aa2eb in ThreadPThread__thread_create () #2 0x00000001009a6c2d in Thread__Fork (M3_EMTrVz_closure=0x101787b20) at ../src/thread/PTHREAD/ThreadPThread.m3:517 #3 0x00000001003b1356 in XMessenger__Start (M3_AQuuui_trsl=0x102256350, M3_AcxOUs_stackSize=20000) at ../src/xvbt/XMessenger.m3:27 #4 0x00000001003cf42e in XClientF__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AQuuui_trsl=0x0) at ../src/xvbt/XClientF.m3:591 #5 0x00000001003cfc23 in XClientF__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClientF.m3:637 #6 0x00000001003ad581 in XClient__DoConnect (M3_BFZe0V_self=0x1022561e0, M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0', M3_BBRY3I_t=0x7fff5fbff430) at ../src/xvbt/XClient.m3:1495 #7 0x000000010040c03c in TrestleClass__Connect (M3_Bd56fi_inst=0x1015b7738, M3_AicXUJ_localOnly=0 '\0') at ../src/vbt/TrestleClass.m3:30 #8 0x0000000100471a5f in Trestle__Connect (M3_Bd56fi_inst=0x1015b7738) at ../src/trestle/Trestle.m3:855 #9 0x0000000100007031 in FormsEditVBT__EditorRootInit (M3_EVrIx4_root=0x1015b78a8, M3_CMge0G_frame=0x1015b7780, M3_Bd56fi_Xdisplay=0x1015b7738, M3_Bd56fi_Xgeometry=0x100163230) at ../src/FormsEditVBT.m3:248 #10 0x0000000100014250 in FormsEdit__main () at ../src/FormsEdit.m3:51 #11 0x0000000100014416 in FormsEdit_M3 (M3_AcxOUs_mode=1) at ../src/FormsEdit.m3:62 #12 0x00000001009937d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:399 #13 0x0000000100992b1a in RTLinker__AddUnitI (M3_DjPxE3_m=0x10013c780) at ../src/runtime/common/RTLinker.m3:113 #14 0x0000000100992bb8 in RTLinker__AddUnit (M3_DjPxE5_b=0x10001428f) at ../src/runtime/common/RTLinker.m3:122 #15 0x0000000100005e14 in main (argc=1, argv=0x7fff5fbff990, envp=0x7fff5fbff9a0) at _m3main.mc:4 (gdb) cont Continuing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:44:46 +0000 Subject: [M3devel] I386_DARWIN Juno crash/hang head In-Reply-To: References: , Message-ID: Yes better. I think I had actually fixed it. The other problem was something related to pthread_self vs. the handle you get from pthread_create or something..I don't understand that part. - Jay Subject: Re: I386_DARWIN Juno crash/hang head From: hosking at cs.purdue.edu Date: Sun, 6 Dec 2009 14:23:33 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Please report back how things behave with the latest commit... On 6 Dec 2009, at 09:48, Jay K wrote:Drat. I've now seen I386_DARWIN head Juno crash and hang, once each (not in a debugger). Here is the second crash (gdb) r Starting program: /Users/jay/cm3/bin/Juno Reading symbols for shared libraries +++++++++++++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00b4dc30 [Switching to process 79884 thread 0x29b7] 0x01710774 in ?? () (gdb) bt #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) (g (gdb) thread apply all bt Thread 9 (process 79884 thread 0x27bf): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b38dd9 in RTHooks__CheckLoadTracedRef (M3_Af40ku_ref=0x21bc434) at ../src/runtime/common/RTCollector.m3:2229 #5 0x00b4d9d8 in ThreadPThread__RunThread (M3_DMxDjQ_me=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:482 #6 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x172b270) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #7 0x968a9155 in _pthread_start () #8 0x968a9012 in thread_start () Thread 8 (process 79884 thread 0x29b7): #0 0x01710774 in ?? () #1 0xb038cf28 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) Thread 7 (process 79884 thread 0x2603): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1712000, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4ac) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005d45b5 in XMessenger__Messenger (M3_EVlqQO_self=0x210bd3c) at ../src/xvbt/XMessenger.m3:69 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1712000) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 6 (process 79884 thread 0x2507): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1711f50, M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x210a134, M3_Bl0jv4_c=0x210a4cc) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x005e0f48 in XInput__FilterXInput (M3_DSd60P_self=0x210bd00) at ../src/xvbt/XInput.m3:102 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711f50) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 5 (process 79884 thread 0x240f): #0 0x968c76fa in select$DARWIN_EXTSN () #1 0x00b524c3 in Unix__select () #2 0x00b4ed8e in ThreadPThread__XIOWait__CallSelect.1129 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:693 #3 0x00b4eacf in ThreadPThread__XIOWait (M3_DMxDjQ_self=0x1711ea0, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:732 #4 0x00b4e5d2 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:635 #5 0x005e0c1d in XInput__WaitForXInput (M3_Bkyxhg_self=0x210bcc4) at ../src/xvbt/XInput.m3:63 #6 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #7 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1711ea0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #8 0x968a9155 in _pthread_start () #9 0x968a9012 in thread_start () Thread 4 (process 79884 thread 0x2303): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x1710550, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x003d3251 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x2040ea0) at ../src/lego/FileBrowserVBT.m3:259 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710550) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 3 (process 79884 thread 0x2203): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968a9dcd in pthread_cond_wait$UNIX2003 () #3 0x00b51431 in ThreadPThread__pthread_cond_wait () #4 0x00b4bfdc in ThreadPThread__XWait (M3_DMxDjQ_self=0x1710430, M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #5 0x00b4c0e8 in Thread__Wait (M3_AYIbX3_m=0x200c3cc, M3_Bl0jv4_c=0x200c3d8) at ../src/thread/PTHREAD/ThreadPThread.m3:204 #6 0x0045691e in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x200c3e8) at ../src/vtext/VTView.m3:111 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1710430) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 2 (process 79884 thread 0x1003): #0 0x9687f46e in __semwait_signal () #1 0x968aa3e6 in _pthread_cond_wait () #2 0x968cf9f8 in pthread_cond_timedwait$UNIX2003 () #3 0x00b51452 in ThreadPThread__pthread_cond_timedwait () #4 0x00b4e3a7 in ThreadPThread__XPause (M3_DMxDjQ_self=0x17100d0, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:591 #5 0x00b4e481 in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:606 #6 0x0061c291 in VBTRep__MeterMaid (M3_EMTrVz_self=0x20079c0) at ../src/vbt/VBTRep.m3:460 #7 0x00b4db0e in ThreadPThread__RunThread (M3_DMxDjQ_me=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:487 #8 0x00b4d823 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x17100d0) at ../src/thread/PTHREAD/ThreadPThread.m3:461 #9 0x968a9155 in _pthread_start () #10 0x968a9012 in thread_start () Thread 1 (process 79884 local thread 0x2e03): #0 0x968782ce in semaphore_wait_signal_trap () #1 0x9687fda5 in pthread_mutex_lock () #2 0x00b514eb in ThreadPThread__pthread_mutex_lock () #3 0x00b509ab in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1359 #4 0x00b387b9 in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=0x224bd68, M3_Dr08L6_p=0xb4b902) at ../src/runtime/common/RTCollector.m3:2148 #5 0x00b4ba9a in ThreadPThread__InitMutex (M3_BIFvRV_m=0x224bd6c, M3_Af40ku_root=0x224bd68, M3_Cg3DND_Clean=0xb4b902) at ../src/thread/PTHREAD/ThreadPThread.m3:108 #6 0x00b4bb12 in ThreadPThread__LockMutex (M3_AYIbX3_m=0x224bd68) at ../src/thread/PTHREAD/ThreadPThread.m3:118 #7 0x0041866a in TextPort__SetText (M3_EBA4wo_v=0x224bcc4, M3_Bd56fi_t=0x2249cc4) at ../src/etext/TextPort.m3:213 #8 0x000242c0 in Editor__Init (M3_ALfX9C_tp=0x224bcc4, M3_Bd56fi_src=0x2249cc4, M3_AicXUJ_readOnly=1 '\001') at ../src/Editor.m3:98 #9 0x0004c4da in Juno__CompileModule (M3_BtMpDB_w=0x20a6f78, M3_Bd56fi_mod=0x2187bfc, M3_EkTcCb_rd=0x2247cc4, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:168 #10 0x0004d134 in Juno__CompileModules (M3_BtMpDB_w=0x20a6f78, M3_EkTcCb_rd=0x219f5a4, M3_Al6NTd_modList=0xbffff884, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #11 0x0005e026 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #12 0x00b3cdb1 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:399 #13 0x00b3c20d in RTLinker__AddUnitI (M3_DjPxE3_m=0x6fe40) at ../src/runtime/common/RTLinker.m3:113 #14 0x00b3c28f in RTLinker__AddUnit (M3_DjPxE5_b=0x5b5cb) at ../src/runtime/common/RTLinker.m3:122 #15 0x00007f4a in main (argc=1, argv=0xbffffa6c, envp=0xbffffa74) at _m3main.mc:4 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 07:55:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 06:55:08 +0000 Subject: [M3devel] race condition setting act.handle? Message-ID: pthread_create(act.handle) followed at some point by use of act.handle in the new thread. Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. What is to cause act.handle to be stored before the new thread starts and uses act.handle? For this reason in Win32 I create the thread suspended, store the handle, resume the thread. Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 7 10:29:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Dec 2009 10:29:00 +0100 Subject: [M3devel] Fwd: [M3commit] CVS Update: cm3 In-Reply-To: <4B1C35FA.1E75.00D7.1@scires.com> References: <20091201165512.EA71F2474001@birch.elegosoft.com> <4B1C35FA.1E75.00D7.1@scires.com> Message-ID: <20091207102900.gohdo855sg8scw0g@mail.elegosoft.com> Quoting Randy Coleburn : > Is everyone ok with the edit I made here? If so, someone should > promote this fix to the release branch. > Also, Is there a reason we should limit this package to POSIX platforms? > If not, we should take out the if statement at line 31 and the > corresponding end. AFAIK CVSup never had any support for Windows platforms. For its optimizations it relies heavily on very Unix-specific functions. I'm not aware that this has changed, but could be wrong. If you find that subsets of the packages compile, we can surely add them for Windows targets, too. Olaf > --Randy > >>>> Randy Coleburn 12/1/2009 5:55 PM >>> > CVSROOT:/usr/cvs > Changes by:rcoleburn at birch.09/12/01 17:55:12 > > Modified files: > cm3/m3-tools/cvsup/suplib/src/: m3makefile > > Log message: > add missing "end" statement at line 58 to correct compile-time syntax error. > > Someone needs to check me on this one. After this change, I don't > get any packages built in cvsup on WindowsXP, I suppose due to some > prerequiste not being met. But at least I don't get the syntax error. > > Not sure why the package m3makefile seems to be limited to POSIX > platforms at line 31. Everything was building on Windows > before.--R.Coleburn > > Here is the compiler output before my correction: > > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib>cm3 -verbose > EVAL ("C:\cm3\bin\cm3.cfg") > --- building in NT386 --- > > cd NT386 > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > EVAL ("m3make.args") > rm .M3SHIP > rm .M3OVERRIDES > "C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args", line > 5: quake runtime error: > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\src\m3makefile, line 263: > syntax error: "end" or "else" expected after "if" > > --procedure-- -line- -file--- > include_dir -- > 5 C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib\NT386\m3make.args > > Fatal Error: package build failed > > seconds #times operation > 0.03 2 removing temporary files > 0.03 other > --------------------------------------------------- > 0.06 TOTAL > > rm m3make.args > cd .. > > C:\cm3\Sandbox\cm3\m3-tools\cvsup\suplib> > > -- 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 From peter.mckinna at gmail.com Mon Dec 7 12:17:50 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 7 Dec 2009 22:17:50 +1100 Subject: [M3devel] AutoFlushWr race. Message-ID: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> Hi, I thought I would have a try at fixing the problem in AutoFlushWr with the little program below. Alas I couldnt get a grip on it so maybe you guys could shed some light. This was with RC4 and on an amd64 linux box. It invariably crashes in FileWr.Seek where some invariant seems to be awry so obviously the worker thread created in AutoFlushWr is hitting or causing a race condition. Probably easily fixed. The thing that intrigued me was that most of the time running it did not cause the normal crash sequence and I had to ctrl-c to get back to the bash prompt which judging from the stack trace something in the threads area is amiss. Regards Peter MODULE Main; IMPORT FileWr,Wr,Rd,AutoFlushWr,Stdio,IO,Fmt,Thread; VAR myout := NEW(AutoFlushWr.T).init(Stdio.stdout); BEGIN FOR i := 0 TO 10000 DO Wr.PutText(myout,Fmt.Int(i) & "\n"); END; (* Thread.Pause(1.0D0); IO.Put("hit enter to end\n"); *) EVAL Rd.GetChar(Stdio.stdin); END Main. ... some iterations and 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) thread apply all bt Thread 3 (Thread 1106278736 (LWP 5197)): #0 0x00007f1a8b9ead29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f1a8bef8d4f in ThreadPThread__pthread_cond_wait (cond=0x24d0170, mutex=0x24d0770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007f1a8bef1ce0 in XWait (self=16_00000000024f2a48, m=16_00000000024ef030, c=16_00000000024ef0b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007f1a8bef214d in Wait (m=16_00000000024ef030, c=16_00000000024ef0b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007f1a8c9e2c62 in Worker (cl=16_00000000024f2a38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007f1a8bef4447 in RunThread (me=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007f1a8bef4140 in ThreadBase (param=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007f1a8b9e6fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007f1a8b75c5ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 139752010405600 (LWP 5194)): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 ---Type to continue, or q to quit--- #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () Thread 1 (LWP 5194): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= ---Type to continue, or q to quit--- RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) Now why is the stack trace duplicated for Thread 1 and Thread 2 and also why is there that last line #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 in the last frame? The first and last frame are duplicated. Havent seen it in other stack traces. Maybe something wrong with my setup? running once more we get ....... some iterations 4311 4312 4313 4314 4315 4316 4317 4318 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** OK here I had to ctrl-c it since it is hung ^C Program received signal SIGINT, Interrupt. 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 (m3gdb) thread apply all bt Thread 3 (Thread 1113143632 (LWP 5200)): #0 0x00007fd82e654d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007fd82eb62d4f in ThreadPThread__pthread_cond_wait (cond=0x19a9170, mutex=0x19a9770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007fd82eb5bce0 in XWait (self=16_00000000019caa48, m=16_00000000019c7030, c=16_00000000019c70b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007fd82eb5c14d in Wait (m=16_00000000019c7030, c=16_00000000019c70b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007fd82f64cc62 in Worker (cl=16_00000000019caa38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007fd82eb5e447 in RunThread (me=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007fd82eb5e140 in ThreadBase (param=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007fd82e650fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007fd82e3c65ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 140566490150624 (LWP 5198)): #0 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007fd82e652bf0 in _L_lock_102 () from /lib/libpthread.so.0 ../../gdb/gdb/dwarf2-frame.c:490: internal-error: Unknown CFI encountered. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Is this a problem with m3gdb? Running this program without the debugger more likely than not will produce a hung program, so I suspect some threading problem. That lll_lock_wait is definitely suspicious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:36:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:36:02 +0000 Subject: [M3devel] AutoFlushWr race. In-Reply-To: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> References: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com> Message-ID: Thank you for looking into stuff Peter. We really need more help. Can you try again either with head or the release commit I just did? Thanks. See: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw/AutoFlushWr.m3 etc. Thanks, - Jay Date: Mon, 7 Dec 2009 22:17:50 +1100 From: peter.mckinna at gmail.com To: m3devel at elegosoft.com Subject: [M3devel] AutoFlushWr race. Hi, I thought I would have a try at fixing the problem in AutoFlushWr with the little program below. Alas I couldnt get a grip on it so maybe you guys could shed some light. This was with RC4 and on an amd64 linux box. It invariably crashes in FileWr.Seek where some invariant seems to be awry so obviously the worker thread created in AutoFlushWr is hitting or causing a race condition. Probably easily fixed. The thing that intrigued me was that most of the time running it did not cause the normal crash sequence and I had to ctrl-c to get back to the bash prompt which judging from the stack trace something in the threads area is amiss. Regards Peter MODULE Main; IMPORT FileWr,Wr,Rd,AutoFlushWr,Stdio,IO,Fmt,Thread; VAR myout := NEW(AutoFlushWr.T).init(Stdio.stdout); BEGIN FOR i := 0 TO 10000 DO Wr.PutText(myout,Fmt.Int(i) & "\n"); END; (* Thread.Pause(1.0D0); IO.Put("hit enter to end\n"); *) EVAL Rd.GetChar(Stdio.stdin); END Main. ... some iterations and 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) thread apply all bt Thread 3 (Thread 1106278736 (LWP 5197)): #0 0x00007f1a8b9ead29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f1a8bef8d4f in ThreadPThread__pthread_cond_wait (cond=0x24d0170, mutex=0x24d0770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007f1a8bef1ce0 in XWait (self=16_00000000024f2a48, m=16_00000000024ef030, c=16_00000000024ef0b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007f1a8bef214d in Wait (m=16_00000000024ef030, c=16_00000000024ef0b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007f1a8c9e2c62 in Worker (cl=16_00000000024f2a38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007f1a8bef4447 in RunThread (me=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007f1a8bef4140 in ThreadBase (param=16_00000000024d0a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007f1a8b9e6fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007f1a8b75c5ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 139752010405600 (LWP 5194)): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 ---Type to continue, or q to quit--- #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () Thread 1 (LWP 5194): #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 #1 0x00007f1a8b6c03f3 in abort () from /lib/libc.so.6 #2 0x00007f1a8beef0ff in Crash () at ../src/runtime/POSIX/RTOS.m3:20 #3 0x00007f1a8bee2b1d in Crash (msg=NIL) at ../src/runtime/common/RTProcess.m3:65 #4 0x00007f1a8bedffba in EndError (crash=TRUE) at ../src/runtime/common/RTError.m3:118 #5 0x00007f1a8bedfcb2 in MsgS (file=16_00007f1a8ccc84d8, line=81, msgA=16_00007f1a8c12dda8, msgB=16_000000000250e078, msgC=16_00007f1a8c12ddf0) at ../src/runtime/common/RTError.m3:40 #6 0x00007f1a8bee048d in Crash (a= ---Type to continue, or q to quit--- RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE, rte=16_00007f1a8c124ca0) at ../src/runtime/common/RTException.m3:79 #7 0x00007f1a8bee0186 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:41 #8 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=FALSE) at ../src/runtime/common/RTException.m3:25 #9 0x00007f1a8bef03db in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:29 #10 0x00007f1a8bee01f6 in DefaultBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:47 #11 0x00007f1a8bee0076 in InvokeBackstop (a= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END, raises=TRUE) at ../src/runtime/common/RTException.m3:25 #12 0x00007f1a8bef04e8 in Raise (act= RECORD exception = 16_00007f1a8c124ca0; arg = 16_000000000000000d; module = 16_00007f1a8ccc8540; line = 81; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_00007f1a8ccc8380; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:51 #13 0x00007f1a8bec791f in Raise (ex=16_00007f1a8ccc8380, arg=NIL, module=16_00007f1a8ccc8540, line=81) at ../src/runtime/common/RTHooks.m3:79 #14 0x00007f1a8c9dd8f4 in Seek (wr=16_00000000024e9448, n=24765) at ../src/rw/FileWr.m3:81 #15 0x00007f1a8c9e0b0e in Seek (wr=16_00000000024ef0d8, n=24765) at ../src/rw/AutoFlushWr.m3:106 #16 0x00007f1a8c9d684e in PutStringDefault (wr=16_00000000024ef0d8, a= {'5','1','7','5','\n'}) at ../src/rw/Wr.m3:193 #17 0x00007f1a8c9d5b4c in FastPutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:105 #18 0x00007f1a8c9d598a in PutText (wr=16_00000000024ef0d8, t=16_000000000250e040) at ../src/rw/Wr.m3:93 #19 0x000000000040108c in Main (mode=1) at ../src/Main.m3:10 #20 0x00007f1a8bedf12b in RunMainBody (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:399 #21 0x00007f1a8bede312 in AddUnitI (m=16_00000000006016c0) at ../src/runtime/common/RTLinker.m3:113 #22 0x00007f1a8bede3b0 in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:8}) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:122 #23 0x0000000000400f2c in main (argc=1, argv=0x7fff6d396f08, envp=0x7fff6d396f18) at _m3main.mc:4 #24 0x00007f1a8b6ab1a6 in __libc_start_main () from /lib/libc.so.6 #25 0x0000000000400e29 in _start () #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 (m3gdb) Now why is the stack trace duplicated for Thread 1 and Thread 2 and also why is there that last line #0 0x00007f1a8b6beed5 in raise () from /lib/libc.so.6 in the last frame? The first and last frame are duplicated. Havent seen it in other stack traces. Maybe something wrong with my setup? running once more we get ....... some iterations 4311 4312 4313 4314 4315 4316 4317 4318 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** OK here I had to ctrl-c it since it is hung ^C Program received signal SIGINT, Interrupt. 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 (m3gdb) thread apply all bt Thread 3 (Thread 1113143632 (LWP 5200)): #0 0x00007fd82e654d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007fd82eb62d4f in ThreadPThread__pthread_cond_wait (cond=0x19a9170, mutex=0x19a9770) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #2 0x00007fd82eb5bce0 in XWait (self=16_00000000019caa48, m=16_00000000019c7030, c=16_00000000019c70b8, alertable=FALSE) at ../src/thread/PTHREAD/ThreadPThread.m3:238 #3 0x00007fd82eb5c14d in Wait (m=16_00000000019c7030, c=16_00000000019c70b8) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #4 0x00007fd82f64cc62 in Worker (cl=16_00000000019caa38) at ../src/rw/AutoFlushWr.m3:211 #5 0x00007fd82eb5e447 in RunThread (me=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:589 #6 0x00007fd82eb5e140 in ThreadBase (param=16_00000000019a9a40) at ../src/thread/PTHREAD/ThreadPThread.m3:565 #7 0x00007fd82e650fc7 in start_thread () from /lib/libpthread.so.0 #8 0x00007fd82e3c65ad in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 140566490150624 (LWP 5198)): #0 0x00007fd82e657384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007fd82e652bf0 in _L_lock_102 () from /lib/libpthread.so.0 ../../gdb/gdb/dwarf2-frame.c:490: internal-error: Unknown CFI encountered. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Is this a problem with m3gdb? Running this program without the debugger more likely than not will produce a hung program, so I suspect some threading problem. That lll_lock_wait is definitely suspicious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:48:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:48:15 +0000 Subject: [M3devel] race condition setting act.handle? Message-ID: I think I resolved this in a simple efficient manner. Please take a look. Perhaps pthread_create is guaranteed to write back the pthread_t before the code runs though? Win32 isn't as amenable to the efficiency here due to the division between handles and thread ids. pthread I'm not really so familiar with, not sure of the efficiency. In particular, where pthreads has pthread_self(), Win32 has three analogs: GetCurrentThreadId() GetCurrentThread() DuplicateHandle(GetCurrentThread()...) GetCurrentThread and GetCurrentThreadId are both fast -- no kernel call. However you can't do all that much with their results, e.g. you can't Suspend/Resume/Close/Wait. GetCurrentThread returns a special /constant/ that always means the current thread, relative to the caller. DuplicateHandle(GetCurrentThread()...) gives you something you can Suspend/Resume/Close/Wait but of course is slower, a kernel call. I have to pay for either the DuplicateHandle or ResumeThread, a wash. pthreads just has the one pthread_self. Fast? I don't know. A kernel call? I don't know. Usable with suspend/resume (np)? Yes. Well on Solaris it is fast: -bash-3.00$ /usr/ccs/bin/dis -F pthread_self /usr/lib/libc.so disassembly for /usr/lib/libc.so thr_self() thr_self: 81 c3 e0 08 retl thr_self+0x4: d0 01 e0 98 ld [%g7 + 0x98], %o0 Recent Linux/x86 is fast: objdump -d /usr/lib/libpthread_a 00001020 <__pthread_self>: 1020: 55 push %ebp 1021: 89 e5 mov %esp,%ebp 1023: 65 a1 50 00 00 00 mov %gs:0x50,%eax 1029: 5d pop %ebp 102a: c3 ret 102b: 90 nop 102c: 8d 74 26 00 lea 0x0(%esi),%esi (geez though, six instructions where only two are needed, crazy..imagine if all code was unoptimal by that factor...) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Subject: race condition setting act.handle? Date: Mon, 7 Dec 2009 06:55:08 +0000 pthread_create(act.handle) followed at some point by use of act.handle in the new thread. Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. What is to cause act.handle to be stored before the new thread starts and uses act.handle? For this reason in Win32 I create the thread suspended, store the handle, resume the thread. Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:49:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:49:40 +0000 Subject: [M3devel] truncation test Message-ID: truncation test. There is content after this line but I bet it won't show. . I bet this won't show up. Let's see. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 13:49:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 12:49:00 +0000 Subject: [M3devel] AutoFlushWr race. In-Reply-To: References: <3d9e5afc0912070317m5aebbe7bpe220f4c215be82cb@mail.gmail.com>, Message-ID: We're still getting emails truncated. Thank you for looking into stuff Peter. We really need more help. Can you try again either with head or the release commit I just did? Thanks. See: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw/AutoFlushWr.m3 etc. Thanks, - Jay > From: jay.krell at cornell.edu > To: peter.mckinna at gmail.com; m3devel at elegosoft.com > Date: Mon, 7 Dec 2009 12:36:02 +0000 > Subject: Re: [M3devel] AutoFlushWr race. > > > Thank you for looking into stuff Peter. We really need more help. > > Can you try again either with head or the release commit I just did? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:04:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:04:30 +0000 Subject: [M3devel] (please ignore, sorry, there will be a few of these) truncation test (65) Message-ID: (please ignore, sorry, there will be a few of these) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:56 +0000 Subject: [M3devel] truncation test (70) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:29 +0000 Subject: [M3devel] truncation test (66) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:05:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:05:04 +0000 Subject: [M3devel] truncation test (65b) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:06:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:06:34 +0000 Subject: [M3devel] truncation test (74) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 123456789012345678901234567890123456789012345678901234567890123456789012345 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:07:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:07:03 +0000 Subject: [M3devel] truncation test (76) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:08:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:08:11 +0000 Subject: [M3devel] truncation test (75) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:09:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:09:30 +0000 Subject: [M3devel] truncation test (77) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:10:55 +0000 Subject: [M3devel] truncation test (80) Message-ID: (please ignore, sorry) 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 abc . Does this appear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:15:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:15:21 +0000 Subject: [M3devel] m3devel email truncation Message-ID: Here are two ways to get email truncated: 1) have a line that contains only a period; I noticed that happened to Tony not long ago, and I can make it happen deliberately. 2) Have a period in column 76. It happened to me in an email about autoflush and I can also make that happen deliberately. Beyond column 76 is ok. Olaf had mentioned it being something about periods. Perhaps I should be sure to yell! or be uncertain? :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 14:35:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 13:35:06 +0000 Subject: [M3devel] build problem diagnosis in caltech-parser test package In-Reply-To: <4B1C3575.1E75.00D7.1@scires.com> References: <4B150A90020000D700067FB8@scires.com>, <4B1C3575.1E75.00D7.1@scires.com> Message-ID: Randy, There is a recurring pattern in the tree related to this. Buildlocal (with overrides) should use the unshipped binary. Because nothing is being shipped. buildship (without overrides) should use the shipped binary. Because things are being shipped right after they are built, or you are using already shipped stuff -- same thing really. (All tools need to be built standalone, in order for the buildlocal version to work. Depending -- $ORIGIN is not compatible with running unshipped binaries. Using full paths is, but requires knowing the paths at link time and linking differently depending on if you are going to run from build_dir or installdir.) To see this in action, search for "override" in *tmpl files. stubgen for example works this. This is probably something that needs more automatic handling? See here: C:\dev2\cm3.2\m3-comm\netobj\src\netobj-ov.tmpl C:\dev2\cm3.2\m3-comm\netobj\src\netobj.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj-ov.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj.tmpl and then very important: C:\dev2\cm3.2\m3-comm\sharedobj\src\m3overrides C:\dev2\cm3.2\m3-comm\netobj\src\m3overrides I have a strong suspicion as well that sharedobj\src\m3overrides and netobj\src\m3overrides should be included in the central m3overrides. (and a strong suspicion as well, as I've said, that this mechanism is flawed; a better implementation I suspect is to /always/ ship, but either on top of the running system, or not to the running system, and then if "not to the running system" passes tests, swap them or move the one to the other, etc.) - Jay Date: Sun, 6 Dec 2009 22:57:02 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problem diagnosis in caltech-parser test package I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Mon Dec 7 14:41:38 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Mon, 07 Dec 2009 14:41:38 +0100 Subject: [M3devel] m3devel email truncation In-Reply-To: References: Message-ID: <20091207144138.u5xm8nkwkk4scogg@mail.elegosoft.com> Ok, thanks, I'll look into it. Mike Quoting Jay K : > > Here are two ways to get email truncated: > > > > 1) have a line that contains only a period; I noticed that > > happened to Tony not long ago, and I can make it happen deliberately. > > > > 2) Have a period in column 76. > > It happened to me in an email about autoflush and I can also > > make that happen deliberately. Beyond column 76 is ok. > > > > Olaf had mentioned it being something about periods. > > > > Perhaps I should be sure to yell! or be uncertain? :) > > > > - Jay > > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Dec 7 15:17:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Dec 2009 14:17:46 +0000 Subject: [M3devel] build problem diagnosis in caltech-parser test package In-Reply-To: References: <4B150A90020000D700067FB8@scires.com>, <4B1C3575.1E75.00D7.1@scires.com>, Message-ID: I guess I should point out that cm3, cm3cg, mklib, the config files are all handled "incorrectly" here. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 7 Dec 2009 13:35:06 +0000 Subject: Re: [M3devel] build problem diagnosis in caltech-parser test package Randy, There is a recurring pattern in the tree related to this. Buildlocal (with overrides) should use the unshipped binary. Because nothing is being shipped. buildship (without overrides) should use the shipped binary. Because things are being shipped right after they are built, or you are using already shipped stuff -- same thing really. (All tools need to be built standalone, in order for the buildlocal version to work. Depending -- $ORIGIN is not compatible with running unshipped binaries. Using full paths is, but requires knowing the paths at link time and linking differently depending on if you are going to run from build_dir or installdir.) To see this in action, search for "override" in *tmpl files. stubgen for example works this. This is probably something that needs more automatic handling? See here: C:\dev2\cm3.2\m3-comm\netobj\src\netobj-ov.tmpl C:\dev2\cm3.2\m3-comm\netobj\src\netobj.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj-ov.tmpl C:\dev2\cm3.2\m3-comm\sharedobj\src\sharedobj.tmpl and then very important: C:\dev2\cm3.2\m3-comm\sharedobj\src\m3overrides C:\dev2\cm3.2\m3-comm\netobj\src\m3overrides I have a strong suspicion as well that sharedobj\src\m3overrides and netobj\src\m3overrides should be included in the central m3overrides. (and a strong suspicion as well, as I've said, that this mechanism is flawed; a better implementation I suspect is to /always/ ship, but either on top of the running system, or not to the running system, and then if "not to the running system" passes tests, swap them or move the one to the other, etc.) - Jay Date: Sun, 6 Dec 2009 22:57:02 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problem diagnosis in caltech-parser test package I am resending this message because I think it may have been overlooked because it came out while the list server was flooding everyone a few days back. --Randy >>> "Randy Coleburn" 12/1/2009 2:32 PM >>> I am listing below the verbose compiler output for the caltech-parser\parserlib\parserlib\test package. This build is from WindowsXP platform. The problem is the command: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 This command should instead be one of the following 2 variants: 1. C:\cm3\bin\ktok ..\src\Calc.t -o CalcTok.i3 2. ..\..\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 depending on whether you want to grab ktok.exe from the public bin folder or from ktok's local build folder. I suspect the former would be the best bet, since the local build folder is often erased after shipping the package. I suspect the problem is in the parser.tmpl file located in C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\src Specifically, the definitions found in lines 11-18 seem suspicious. Since I am not very familiar with this package, I would prefer someone else to make the correction. Compiler output is below: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test>cm3 -verbose EVAL ("C:\cm3\bin\cm3.cfg") --- building in NT386 --- cd NT386 LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\bin/..\pkg\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 5 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed seconds #times operation 0.01 1 garbage collection 0.06 other --------------------------------------------------- 0.07 TOTAL rm m3make.args cd .. C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test> Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 7 15:27:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Dec 2009 15:27:14 +0100 Subject: [M3devel] m3devel email truncation In-Reply-To: References: Message-ID: <20091207152714.rt753229gkww4ccc@mail.elegosoft.com> Quoting Jay K : > Here are two ways to get email truncated: > > 1) have a line that contains only a period; I noticed that > > happened to Tony not long ago, and I can make it happen deliberately. > > 2) Have a period in column 76. > > It happened to me in an email about autoflush and I can also > make that happen deliberately. Beyond column 76 is ok. > > Olaf had mentioned it being something about periods. A period alone on a line is an ancient convention for EOF (from the ages when terminals with serial lines connected via 2400 or 9600 baud were in common use). The mail servers here at NSN do the same thing still (ignore everything after a period :-). I don't think it is required by any standard (though I'm not sure here), and I assume it is buried deep in one of our filters/scripts/scanners which process the mails. So it may not be easy to locate. I'm not sure why column 76 should be special, though one could assume that's where wrapping text occurs so that the period is in column one on the next line. > Perhaps I should be sure to yell! or be uncertain? :) No need to yell; Mike will do his best. He's got many other tasks though... 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 From dabenavidesd at yahoo.es Mon Dec 7 17:03:45 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 7 Dec 2009 16:03:45 +0000 (GMT) Subject: [M3devel] Looking to update cm3 manual page. Message-ID: <611913.58311.qm@web23606.mail.ird.yahoo.com> Hi: probably you want to take look the DEBUG pragma of Cambridge Modula-3 cam3: http://web.archive.org/web/20040103230522/www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/m3.pdf or here http://web.archive.org/web/20040714091911/http://www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/index.html the pragmas explained there are actually documented to be in the sources of cm3 see history notes http://opencm3.net/about-cm3.html I think there is a table of compiler options for cam3 (page 54 and 55 which have some of it also listed in the cm3 -? message of the pdf document above) and of "pass 0" of it which are listed there on page 57. Page 56 have a list of pragmas ( http://web.archive.org/web/20050112061744/www.rrw-net.co.uk/semiramis-org-uk/rrw/docs/m3/node42.html#SECTION00630000000000000000 ) also see the traditional CM3 and DEC SRC pragma list (http://opencm3.net/doc/help/cm3/pragmas.html) but there isn't more information about <*INTRINSIC*> pragma than see http://opencm3.net/about-cm3.html I think there other DEC in-house pragmas which the cm3 sources inhereted and are not linked to the compiler process itself like PRAGMA SPEC <*SPEC ...*> (i.e. http://opencm3.net/doc/help/gen_html/libm3/src/sequence/Sequence.ig.html see doc in http://web.archive.org/web/19970605182158/www.research.digital.com/SRC/esc/Esc-speclang.html) and those of .lm3 Larch Modula-3 checking (they were in .lm3 files i.e m3-libs/m3core/src/text/Text.lm3 , I think compiler didn't handle it. but still there is a syntax grammar that can be used to build a syntax checker of it http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-72.html ). Another pragma that could be documented is the one present and explained in the documentation <*TRACE*>: http://apotheca.hpl.hp.com/ftp/pub/DEC/SRC/hypertext/Modula-3/user.html see source code in m3-sys/m3front/src/misc/Token.m3 and documentation in the SRC Modula-3 version 2.11 documentation: Hope this can be useful for the man page and improved documentation you can take in account --- El mi?, 2/12/09, Peter Eiserloh escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Looking to update cm3 manual page. > Para: "M3Devel" > Fecha: mi?rcoles, 2 de diciembre, 2009 12:01 > Hi all, > > It has been more than half a year since I last looked at > the > CM3 manual page. I am now looking at the it in > preparation > for the release of version 5.8, and noticing some > deficiencies. > > I asking for help in identifying any further places it is > lacking. > I can integrate any feedback into a revised manual page, > and > submit an updated version back to the archives. > > > Currently identified deficiencies: > > o The manual page should explicitly state which version of > the > compiler it documents. > > o The sub-section "Expected Directory Structure" needs a > better > discussion, especially an introduction. > > o The discussion of mode option "-ship" mentions > environment > variable CM3_INSTALL_ROOT, yet in cm3.cfg we set > INSTALL_ROOT > without the "CM3_" prefix. This should > be resolved. > > ** What is the exact meaning of these two? Is > one recognized > by the compiler, and the other by > the supporting quake > code? > > o The ENVIRONMENT section does not mention > CM3_INSTALL_ROOT > at all. Add a discussion about both > INSTALL_ROOT, and > CM3_INSTALL_ROOT. > > ** Am I missing any other environment variables? > > o Missing command line options for the compiler: > > - I currently have "-g", but no discussion of > -gstabs. > No discussion about not supporting DWARF (or > do we?). > > o Compiler unique language features, (i.e., pragmas). > The > reference books (Nelson, and Harbison) give a list > of > suggested pragmas. The manual page should list > the ones > supported by the CM3 compiler explicitly, and show > their > syntax. > > ** Can someone list for me the pragmas supported by > the > current (5.8.4) compiler. > > o Should list any limitations of either the compiler, or > the library suite provided with the compiler. > > > For example, the WIDECHAR is limited by its 16-bit > size > to only a portion of the unicode character set > (the basic multi lingual plane), whereas a unicode > character is 20-bits, and we would need either a > 24-bit or 32-bit sized type to contain it all. > > ** Are there any other known limitations of the > compiler, > or library suite? > - length of identifier? > - length of TEXT (ie, > memory) > - length of filenames, or > pathname > (some architectures > may have differences, > ie MS-Windows). > > o There should be a discussion of the @m3XXX runtime > library command line options. > > o There should be an EXAMPLE section, with example > source code (Hello world), along with supporting > m3makefile. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > > | > +--------------------------------------------------------+ > > > > From hosking at cs.purdue.edu Mon Dec 7 18:42:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Dec 2009 12:42:13 -0500 Subject: [M3devel] race condition setting act.handle? In-Reply-To: References: Message-ID: On 7 Dec 2009, at 01:55, Jay K wrote: > pthread_create(act.handle) followed at some point by use of act.handle in the new thread. > Or possibly getting on the list of threads in the new thread and then a third thread looking at that list. Good question. Previously we had fork inside activeMu, which prevented the forked thread running until the parent release activeMu. Now we don't. Perhaps that was the problem. > > > What is to cause act.handle to be stored before the new thread starts and uses act.handle? > > > For this reason in Win32 I create the thread suspended, store the handle, resume the thread. > Apparently there is no direct equivalent in pthreads, you have to use your own mutex+condition variable. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 9 14:15:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Dec 2009 13:15:47 +0000 Subject: [M3devel] full source paths in debug info? Message-ID: I'll check the archive..but..we should have full paths to source files in debug information. That is what you always get with C and C++ on Windows. I understand they aren't particularly useful when binaries are copied across machines. But they are very useful when they aren't. Real life scenario, the debugger shows me: 0012fc2c 0041fd50 stubgen!Formatter__PutText+0xc6 [..\src\formatter\Formatter.m3 @ 275] 0012fc98 00410192 stubgen!IntfStubCode__Header+0x90 [..\src\IntfStubCode.m3 @ 25] 0012fd78 00409444 stubgen!StubCode__GenStub+0x14b [..\src\StubCode.m3 @ 91] 0012fdc8 00409117 stubgen!AstToType__ProcessNetObj+0x1e7 [..\src\AstToType.m3 @123] 0012fe38 00422b2b stubgen!AstToType__OneStub+0x59e [..\src\AstToType.m3 @ 95] 0012fe88 00443305 stubgen!Main__DoRun+0x3db [..\src\Main.m3 @ 64] 0012febc 00422b99 stubgen!M3ToolFrame__Startup+0x87 [..\src\toolframe\M3ToolFrame.m3 @ 27] 0012fee0 0056c3f4 stubgen!Main_M3+0x35 [..\src\Main.m3 @ 76] 0012ff24 0056b9cc stubgen!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLinker.m3 @ 399] If we did things correctly, I'd just copy/paste these paths into the file.open dialog. Instead I get to be slower. Here is C++ for example: C:\dev2\cm3.2\m3-ui\zeus\NT386>type t.c int main() { __debugbreak(); } C:\dev2\cm3.2\m3-ui\zeus\NT386>cl -Zi t.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. C:\dev2\cm3.2\m3-ui\zeus\NT386>\bin\x86\cdb.exe -g t.exe t!main+0x3: 00401013 cc int 3 0:000> .lines Line number information will be loaded 0:000> u . t!main+0x3 [c:\dev2\cm3.2\m3-ui\zeus\nt386\t.c @ 3]: - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 9 15:16:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Dec 2009 14:16:51 +0000 Subject: [M3devel] deadlock in Win32 threads? Message-ID: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 9 17:13:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Dec 2009 11:13:03 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: Message-ID: <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 07:59:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 06:59:34 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 08:43:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 07:43:42 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, Message-ID: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 10 10:18:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Dec 2009 10:18:24 +0100 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> Quoting Jay K : > Hm. First, what changed is probably the movement of stuff from > traced to untraced?? > > Which makes it more efficient and more like pthreads. > > I might try putting that back. > > What I have now though, is that in T, Mutex, and Condition, I put an > integer field writeToBlahBlah. > > Every time before Lock(giant), whatever, t, m, c, I have I write to > that field. > > That drastically mitigates this problem and it goes away. I don't really feel confident with such solutions. Maybe I'm a bit old-fashioned, but I think that code like a threading subsystem should be completely understood and `correct' (according to all available means). In my experience it is almost impossible to _test_ the `correctness' of concurrent and concurrency implementations, as the next usage scenario or even a simple hardware upgrade will reveal one unsafe or unprotected critical region after the other. And reveal doesn't mean `point to' here, but just indicate that something must be wrong somewhere ;-) So to keep the good spirit of Modula-3, I'd really favour a simple and completely understandable implementation even if it has some performance drawbacks. Deadlock can be completely avoided if all critical resources are known and a well-defined locking order is heeded for each access. If there is only one code path that may use another order, this deadlock will occur earlier or later, preferably when there is also stress to get something else working for a milestone or a release. All this should not be misinterpreted to depreciate testing; but there can never be enough tests, and there is only a limited time to perform them regularly. Olaf > However that still leaves me with a similar deadlock. > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > This thread is stuck trying to get the heap lock. > > It is I presume "inCritical" already. > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > The first thread has the heap lock, and isn't giving it up: > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > > > Suspending the second thread does work, but it stays inCritical. > > I'm guessing at some of this. > > > > The giant lock is no longer relevant. > > > > > > I don't see why pthreads doesn't behave the same. > > > > I'll have to read the code more. > > > > Hm. inCritical maybe shouldn't be set actually? > > I'll dig more. > > > > > > - Jay > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > > > Jay, you're the one closest to the Win32 threading code these days. > Hope you can track it down. > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I > could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild > everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll > probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe > [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 > [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 > [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 > [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe > [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 > [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 > [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 > [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 > [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 > [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 > [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c > [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 > [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf > [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within > the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is > obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it > works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers > make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references > within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > -- 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 From jay.krell at cornell.edu Thu Dec 10 13:34:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 12:34:08 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <20091210101824.c1kr3rplgk4k4gwk@mail.elegosoft.com> Message-ID: I understand, but I don't understand Birrel's algorithm, though I can see we did and do implement it exactly. He stated and implemented it at a time where touching pointers didn't call into the garbage collector. The idea that just touching a pointer call into all that code is a bit hard to reason about imho...since I don't really understand all that code.. Our use of the giant lock in LockMutex/UnlockMutex appears to be in the interest of implementing a simple optimization suggested by Birrel, but one we didn't have. Ultimately I believe we remove the giant lock and emulate Java's implementation, but I don't understant it either. I can implement faithfully but I'd like to understand it. Maybe I can/should do that earlier rather than later? That moves us from not-well-understood place to another, but where the one is clearly better. - Jay > Date: Thu, 10 Dec 2009 10:18:24 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Quoting Jay K : > > > Hm. First, what changed is probably the movement of stuff from > > traced to untraced?? > > > > Which makes it more efficient and more like pthreads. > > > > I might try putting that back. > > > > What I have now though, is that in T, Mutex, and Condition, I put an > > integer field writeToBlahBlah. > > > > Every time before Lock(giant), whatever, t, m, c, I have I write to > > that field. > > > > That drastically mitigates this problem and it goes away. > > I don't really feel confident with such solutions. Maybe I'm a bit > old-fashioned, but I think that code like a threading subsystem should > be completely understood and `correct' (according to all available means). > > In my experience it is almost impossible to _test_ the `correctness' of > concurrent and concurrency implementations, as the next usage scenario or > even a simple hardware upgrade will reveal one unsafe or unprotected > critical region after the other. And reveal doesn't mean `point to' here, > but just indicate that something must be wrong somewhere ;-) > > So to keep the good spirit of Modula-3, I'd really favour a simple and > completely understandable implementation even if it has some performance > drawbacks. > > Deadlock can be completely avoided if all critical resources are known > and a well-defined locking order is heeded for each access. If there is > only one code path that may use another order, this deadlock will occur > earlier or later, preferably when there is also stress to get something > else working for a milestone or a release. > > All this should not be misinterpreted to depreciate testing; but there > can never be enough tests, and there is only a limited time to perform > them regularly. > > Olaf > > > However that still leaves me with a similar deadlock. > > > > This thread is stuck trying to suspend everyone: > > > > 0:000> ~*k > > > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > > This thread is stuck trying to get the heap lock. > > > > It is I presume "inCritical" already. > > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > > ChildEBP RetAddr > > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > > > > > > The first thread has the heap lock, and isn't giving it up: > > > > > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > > 0:000> ?? m3core!ThreadWin32__heapLock > > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > > +0x00c OwningThread : 0x00001258 > > > > > > > > > > Suspending the second thread does work, but it stays inCritical. > > > > I'm guessing at some of this. > > > > > > > > The giant lock is no longer relevant. > > > > > > > > > > > > I don't see why pthreads doesn't behave the same. > > > > > > > > I'll have to read the code more. > > > > > > > > Hm. inCritical maybe shouldn't be set actually? > > > > I'll dig more. > > > > > > > > > > > > - Jay > > > > > > > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > > From: hosking at cs.purdue.edu > > Date: Wed, 9 Dec 2009 11:13:03 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > > > > > > > Jay, you're the one closest to the Win32 threading code these days. > > Hope you can track it down. > > > > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > > > Win32. > > > > I have a wierd system..but I think the bug is real. > > In particular I was testing a small threading change on head. > > How alertable is managed, to remove its write in LockMutex, so I > > could remove the giant lock there. > > But I just had the alertable changes. > > > > > > It was hanging starting Juno. > > So I tried to test release. > > You can't use head Juno with release m3core...and I didn't rebuild > > everything. I'll do that. > > So I patched up release m3core to be binary compatible. (I'll > > probably check that in.) > > > > > > Juno still hangs. > > > > > > Here is what I see: > > > > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > > ~ is thread; * is all; k is stack. > > > > [edited] > > > > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > > ChildEBP RetAddr > > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > [c:\dev2\cm3 > > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 > > [..\src\thread\WIN32\ThreadWin32.m3 > > @ 960] > > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 > > [..\src\runtime\common\R > > TCollector.m3 @ 2253] > > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 > > [..\src\thread\WIN32\Thread > > Win32.m3 @ 111] > > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > > ... > > > > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > > ChildEBP RetAddr > > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > [c:\dev2\cm > > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 > > [..\src\thread\WIN32\ThreadWin32 > > .m3 @ 276] > > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 > > [..\src\thread\WIN32\ThreadWin > > 32.m3 @ 995] > > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 > > [..\src\runtime\common\R > > TCollector.m3 @ 716] > > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 > > [..\src\runtime\common\RTC > > ollector.m3 @ 666] > > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 > > [..\src\runtime\common\R > > TCollector.m3 @ 671] > > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 > > [..\src\runtime\common\RT > > Allocator.m3 @ 364] > > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c > > [..\src\runtime\common\R > > TAllocator.m3 @ 222] > > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 > > [..\src\runtime\common\ > > RTAllocator.m3 @ 120] > > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf > > [..\src\JunoCompile.m3 > > @ 987] > > ... > > > > > > Let's look at two of our important locks: > > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > > > > 0:006> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 2 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000b0 > > +0x010 LockSemaphore : 0x00000708 > > +0x014 SpinCount : 0 > > > > > > 0:006> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000b34 > > +0x010 LockSemaphore : 0x000006ec > > +0x014 SpinCount : 0 > > > > > > So you can see there is a circularity and deadlock. > > Thread 6 owns giant lock and is waiting for heap lock. > > Thread 7 owns heap lock and is waiting for giant lock. > > > > > > This occurs because Win32 LockMutex uses traced references within > > the giant lock. ? > > Use of traced references implies a possible need to take the heap lock. > > Doing darn near anything implies a need to use the giant lock. > > > > > > Any ideas Tony? > > > > > > I'm not crazy or have a messed up tree, right? > > I mean, now that I've discussed it, the deadlock potential is > > obviously there, right? > > > > > > Pthreads is safe of course, no giant lock. > > > > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > > That should help? > > The giant lock would still remain though. > > > > > > Now, we know that condition variables are implementable well enough on Win32. > > Either with a giant lock, or how Java does it. > > Aside: I don't fully understand the Java implementation, but if it > > works, it is goodness. > > It has no giant lock. I don't understand how the sequence numbers > > make it work. > > > > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > > that it works at ll..doesn't interact well with traced references > > within its own implementation? > > Maybe this stuff can be teased apart? > > > > > > Same thing with a coherent (I think) release build: > > > > 0:008> ~*k > > > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > > > ... > > > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > > ChildEBP RetAddr > > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > > > > 0:008> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 5 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000d0 > > +0x010 LockSemaphore : 0x00000700 > > +0x014 SpinCount : 0 > > > > > > 0:008> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000080 > > +0x010 LockSemaphore : 0x000006fc > > +0x014 SpinCount : 0 > > > > > > 80 has the heap lock and is trying to get the giant lock > > D0 has the giant lock and is trying to get the heap lock > > Because of the use of traced references in LockMutex. > > > > > > - Jay > > > > > > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 10 17:10:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 11:10:58 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> Message-ID: <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> The second thread should *not* be inCritical when trying to LockHeap. Are you sure that is the case? As it stands you need to be able to suspend a thread even if it is waiting on the heap lock (i.e., because the collector thread already holds the lock). On 10 Dec 2009, at 01:59, Jay K wrote: > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > From hosking at cs.purdue.edu Thu Dec 10 17:12:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 11:12:45 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, Message-ID: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 17:12:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 16:12:58 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> References: , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu> , <82B3B541-B006-4E6A-9053-1FF73974CDF3@cs.purdue.edu> Message-ID: I was wrong on that point. Upon debugging it I found the stack pointer was deemed bad, because I had context* vs. context** wrong. That we even check the stack pointer is dubious but it is the historical behavior -- I merely made the code to do it far more direct/faster/reliable. - Jay > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:10:58 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > The second thread should *not* be inCritical when trying to LockHeap. Are you sure that is the case? As it stands you need to be able to suspend a thread even if it is waiting on the heap lock (i.e., because the collector thread already holds the lock). > > On 10 Dec 2009, at 01:59, Jay K wrote: > > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > > Which makes it more efficient and more like pthreads. > > I might try putting that back. > > > > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > > That drastically mitigates this problem and it goes away. > > > > > > However that still leaves me with a similar deadlock. > > > > > > This thread is stuck trying to suspend everyone: > > > > 0:000> ~*k > > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > > > > This thread is stuck trying to get the heap lock. > > It is I presume "inCritical" already. > > > > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > > ChildEBP RetAddr > > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > > > > The first thread has the heap lock, and isn't giving it up: > > > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > > 0:000> ?? m3core!ThreadWin32__heapLock > > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > > +0x00c OwningThread : 0x00001258 > > > > > > Suspending the second thread does work, but it stays inCritical. > > I'm guessing at some of this. > > > > The giant lock is no longer relevant. > > > > > > I don't see why pthreads doesn't behave the same. > > > > I'll have to read the code more. > > > > Hm. inCritical maybe shouldn't be set actually? > > I'll dig more. > > > > > > - Jay > > > > > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > > From: hosking at cs.purdue.edu > > Date: Wed, 9 Dec 2009 11:13:03 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > > > On 9 Dec 2009, at 09:16, Jay K wrote: > > > > Win32. > > > > I have a wierd system..but I think the bug is real. > > In particular I was testing a small threading change on head. > > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > > But I just had the alertable changes. > > > > > > It was hanging starting Juno. > > So I tried to test release. > > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > > > > Juno still hangs. > > > > > > Here is what I see: > > > > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > > ~ is thread; * is all; k is stack. > > > > [edited] > > > > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > > ChildEBP RetAddr > > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > > @ 960] > > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > > TCollector.m3 @ 2253] > > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > > Win32.m3 @ 111] > > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > > ... > > > > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > > ChildEBP RetAddr > > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > > .m3 @ 276] > > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > > 32.m3 @ 995] > > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > > TCollector.m3 @ 716] > > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > > ollector.m3 @ 666] > > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > > TCollector.m3 @ 671] > > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > > Allocator.m3 @ 364] > > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > > TAllocator.m3 @ 222] > > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > > RTAllocator.m3 @ 120] > > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > > @ 987] > > ... > > > > > > Let's look at two of our important locks: > > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > > > > 0:006> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 2 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000b0 > > +0x010 LockSemaphore : 0x00000708 > > +0x014 SpinCount : 0 > > > > > > 0:006> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000b34 > > +0x010 LockSemaphore : 0x000006ec > > +0x014 SpinCount : 0 > > > > > > So you can see there is a circularity and deadlock. > > Thread 6 owns giant lock and is waiting for heap lock. > > Thread 7 owns heap lock and is waiting for giant lock. > > > > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > > Use of traced references implies a possible need to take the heap lock. > > Doing darn near anything implies a need to use the giant lock. > > > > > > Any ideas Tony? > > > > > > I'm not crazy or have a messed up tree, right? > > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > > > > Pthreads is safe of course, no giant lock. > > > > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > > That should help? > > The giant lock would still remain though. > > > > > > Now, we know that condition variables are implementable well enough on Win32. > > Either with a giant lock, or how Java does it. > > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > > It has no giant lock. I don't understand how the sequence numbers make it work. > > > > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > > that it works at ll..doesn't interact well with traced references within its own implementation? > > Maybe this stuff can be teased apart? > > > > > > Same thing with a coherent (I think) release build: > > > > 0:008> ~*k > > > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > > ChildEBP RetAddr > > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > > > ... > > > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > > ChildEBP RetAddr > > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > > > > 0:008> ?? m3core!ThreadWin32__giant > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 5 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x000000d0 > > +0x010 LockSemaphore : 0x00000700 > > +0x014 SpinCount : 0 > > > > > > 0:008> ?? m3core!ThreadWin32__heap > > struct _RTL_CRITICAL_SECTION > > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > > +0x004 LockCount : 1 > > +0x008 RecursionCount : 1 > > +0x00c OwningThread : 0x00000080 > > +0x010 LockSemaphore : 0x000006fc > > +0x014 SpinCount : 0 > > > > > > 80 has the heap lock and is trying to get the giant lock > > D0 has the giant lock and is trying to get the heap lock > > Because of the use of traced references in LockMutex. > > > > > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 17:44:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 16:44:12 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: ok. LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. BroadcastHeap just sets a boolean that is looked at by UnlockHeap. Not my doing, but I just moved it from head to release. LockMutex I changed to just EnterCriticalSection. My doing. BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, then BroadcastHeap would have to call Broadcast and take the giant lock. I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. - Jay From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 10 18:32:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Dec 2009 12:32:36 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> I thought you were saying you had a problem with access to traced state... On 10 Dec 2009, at 11:44, Jay K wrote: > ok. > > LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. > BroadcastHeap just sets a boolean that is looked at by UnlockHeap. > Not my doing, but I just moved it from head to release. > LockMutex I changed to just EnterCriticalSection. > My doing. > > > BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. > That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, > then BroadcastHeap would have to call Broadcast and take the giant lock. > > > I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:12:45 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. > > On 10 Dec 2009, at 02:43, Jay K wrote: > > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 10 18:33:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 10 Dec 2009 17:33:42 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> References: , , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , , , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> , <5730CD9F-F79C-4DB1-BC3E-1ED730E28887@cs.purdue.edu> Message-ID: I did. I was. I think it is ok now. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 12:32:36 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I thought you were saying you had a problem with access to traced state... On 10 Dec 2009, at 11:44, Jay K wrote: ok. LockMutex and BroadcastHeap no longer take the giant lock, for different reasons. BroadcastHeap just sets a boolean that is looked at by UnlockHeap. Not my doing, but I just moved it from head to release. LockMutex I changed to just EnterCriticalSection. My doing. BroadcastHeap need not take the heap lock either, it's just doing an atomic store, but its caller in this case already has it. That probably has to be either way. If the caller didn't have it, and was therefore going to be leaving it soon, then BroadcastHeap would have to call Broadcast and take the giant lock. I'd just as soon not have the thread code touch any traced data, but Thread.T, Thread.Mutex, Thread.Condition are all traced. - Jay From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:22:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:22:48 +0000 Subject: [M3devel] "port simple race condition fix from head related to stopping a thread before/after it has any traced references" In-Reply-To: <20091211111426.0EA142474001@birch.elegosoft.com> References: <20091211111426.0EA142474001@birch.elegosoft.com> Message-ID: Something is fishy here. The change is fine, but there could only be a problem if suspending the thread didn't work? You know, the stack value shouldn't be changing? I'm pretty sure I saw this be a problem on some configuration, but maybe it was only user threads and maybe they are relevantly different? Also Tony is it ok to RTHeapRep.FlushThreadState unconditionally here? - Jay > Date: Fri, 11 Dec 2009 12:14:26 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 12:14:26 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > release_branch_cm3_5_8 > ThreadPThreadC.c > > Log message: > port simple race condition fix from head related to stopping a thread before/after it has any traced references > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:35:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:35:02 +0000 Subject: [M3devel] slight differences in m3core release vs. head? Message-ID: Tony, which versions do you prefer in which branch? C:\dev2\cm3.release_branch_cm3_5_8\m3-libs\m3core\src\runtime\common>diff -u C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3 RTHeapStats.m3 --- C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3 2009-12- 10 09:04:05.546875000 -0800 +++ RTHeapStats.m3 2009-12-11 02:51:53.468750000 -0800 @@ -330,7 +330,7 @@ VAR fp: UNTRACED REF ADDRESS := start; BEGIN (* scan the stack or registers *) - WHILE fp < stop DO + WHILE fp <= stop DO WITH page = RTHeapRep.AddressToPage(fp^), d = page.desc DO IF page # NIL AND d.space = RTHeapRep.Space.Current THEN VisitPage(page); C:\dev2\cm3.release_branch_cm3_5_8\m3-libs\m3core\src\runtime\common>diff -u C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3 RTCollector.m3 --- C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3 2009-12- 11 02:50:02.234375000 -0800 +++ RTCollector.m3 2009-12-11 02:51:44.781250000 -0800 @@ -519,7 +519,9 @@ PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN - IF NOT (start < stop) THEN RETURN END; + IF start = NIL AND stop = NIL THEN + RETURN; + END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO @@ -2210,7 +2212,7 @@ END; END WeakCleaner; There are also a bunch of user thread diffs I haven't looked at closely. And a bunch of diffs I understand. I think off by one thing in NoteStackLocations is subtle. The ranges come from code that might not be so precise or might be themselves off by one. I believe in Win32 I pass in for stop the "just past the end" value. In which case you want "<". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 12:44:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 11:44:27 +0000 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: Btw, I don't understand how all the barriers work so seemingly lock free. Or maybe they do often take locks? That is why I don't trust arbitrary invocations of barriers, since I don't know how long the results stay valid. I really just need to read and internalize this barrier stuff. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 11:12:45 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. On 10 Dec 2009, at 02:43, Jay K wrote: I think it is ok now. Though there is still some mystery, like why did it work before? There may also still be a race between the extra writes I put and the "real" uses of traced data. Maybe I can reduce the traced data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 10 Dec 2009 06:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] deadlock in Win32 threads? Hm. First, what changed is probably the movement of stuff from traced to untraced?? Which makes it more efficient and more like pthreads. I might try putting that back. What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. Every time before Lock(giant), whatever, t, m, c, I have I write to that field. That drastically mitigates this problem and it goes away. However that still leaves me with a similar deadlock. This thread is stuck trying to suspend everyone: 0:000> ~*k . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 This thread is stuck trying to get the heap lock. It is I presume "inCritical" already. 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 The first thread has the heap lock, and isn't giving it up: 01ebffec 00000000 kernel32!BaseThreadStart+0x37 0:000> ?? m3core!ThreadWin32__heapLock struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 +0x00c OwningThread : 0x00001258 Suspending the second thread does work, but it stays inCritical. I'm guessing at some of this. The giant lock is no longer relevant. I don't see why pthreads doesn't behave the same. I'll have to read the code more. Hm. inCritical maybe shouldn't be set actually? I'll dig more. - Jay Subject: Re: [M3devel] deadlock in Win32 threads? From: hosking at cs.purdue.edu Date: Wed, 9 Dec 2009 11:13:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. On 9 Dec 2009, at 09:16, Jay K wrote: Win32. I have a wierd system..but I think the bug is real. In particular I was testing a small threading change on head. How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. But I just had the alertable changes. It was hanging starting Juno. So I tried to test release. You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. So I patched up release m3core to be binary compatible. (I'll probably check that in.) Juno still hangs. Here is what I see: 0:006> ~*k This funny thing is like gdb's "thread apply all bt". ~ is thread; * is all; k is stack. [edited] 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen ChildEBP RetAddr 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 @ 960] 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R TCollector.m3 @ 2253] 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread Win32.m3 @ 111] 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] ... 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 .m3 @ 276] 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin 32.m3 @ 995] 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R TCollector.m3 @ 716] 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC ollector.m3 @ 666] 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R TCollector.m3 @ 671] 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT Allocator.m3 @ 364] 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R TAllocator.m3 @ 222] 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ RTAllocator.m3 @ 120] 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 @ 987] ... Let's look at two of our important locks: ?? is the C++ expression evaluator -- the "good" expression evaluator. 0:006> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 2 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000b0 +0x010 LockSemaphore : 0x00000708 +0x014 SpinCount : 0 0:006> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000b34 +0x010 LockSemaphore : 0x000006ec +0x014 SpinCount : 0 So you can see there is a circularity and deadlock. Thread 6 owns giant lock and is waiting for heap lock. Thread 7 owns heap lock and is waiting for giant lock. This occurs because Win32 LockMutex uses traced references within the giant lock. ? Use of traced references implies a possible need to take the heap lock. Doing darn near anything implies a need to use the giant lock. Any ideas Tony? I'm not crazy or have a messed up tree, right? I mean, now that I've discussed it, the deadlock potential is obviously there, right? Pthreads is safe of course, no giant lock. I was about to remove the giant lock from LockMutex/UnlockMutex. That should help? The giant lock would still remain though. Now, we know that condition variables are implementable well enough on Win32. Either with a giant lock, or how Java does it. Aside: I don't fully understand the Java implementation, but if it works, it is goodness. It has no giant lock. I don't understand how the sequence numbers make it work. However the Modula-3 giant lock implementation..I am trusting Birrel here that it works at ll..doesn't interact well with traced references within its own implementation? Maybe this stuff can be teased apart? Same thing with a coherent (I think) release build: 0:008> ~*k 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed ... 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen ChildEBP RetAddr 0240fc98 7c90df5a ntdll!KiFastSystemCallRet 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 0:008> ?? m3core!ThreadWin32__giant struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 5 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x000000d0 +0x010 LockSemaphore : 0x00000700 +0x014 SpinCount : 0 0:008> ?? m3core!ThreadWin32__heap struct _RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 1 +0x008 RecursionCount : 1 +0x00c OwningThread : 0x00000080 +0x010 LockSemaphore : 0x000006fc +0x014 SpinCount : 0 80 has the heap lock and is trying to get the giant lock D0 has the giant lock and is trying to get the heap lock Because of the use of traced references in LockMutex. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 13:08:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 12:08:27 +0000 Subject: [M3devel] "start, limit" vs. "start, stop" In-Reply-To: <20091211120558.37E0F2474001@birch.elegosoft.com> References: <20091211120558.37E0F2474001@birch.elegosoft.com> Message-ID: > note that there are still "start, stop" pairs, in addition to the > "start, limit" pairs There are still some "start, stop", but they are consistent, things compile. C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTCollector.m3(519):PROCEDURE NoteStackLocations (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(297):PROCEDURE GetThread (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(329):PROCEDURE ScanPages (start, stop: ADDRESS) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(353):PROCEDURE ScanThreadRoots (start, stop: ADDRESS; on_stack: BOOLEAN) = C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTHeapStats.m3(383):PROCEDURE ScanThreadPageRoots (start, stop: ADDRESS; on_stack: BOOLEAN) = C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3(976):PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) = C:\dev2\cm3.2\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3(808):PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) = I think the names are in the type, like for calling with named parameters, but the functions don't actually have to match. The perfectionist in me says they should all be consistent though. The pragmatist says basically no change is worthwhile here, even the ones already made. - Jay > Date: Fri, 11 Dec 2009 13:05:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 13:05:58 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: Tag: > release_branch_cm3_5_8 > RTThread.i3 > cm3/m3-libs/m3core/src/thread/POSIX/: Tag: > release_branch_cm3_5_8 > ThreadPosix.i3 > ThreadPosix.m3 > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > release_branch_cm3_5_8 > ThreadPThread.m3 > cm3/m3-libs/m3core/src/thread/WIN32/: Tag: > release_branch_cm3_5_8 > ThreadWin32.m3 > > Log message: > port from head: rename parameter in function pointer type from "stop" > to "limit" > note that there are still "start, stop" pairs, in addition to the > "start, limit" pairs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 14:55:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 08:55:26 -0500 Subject: [M3devel] deadlock in Win32 threads? In-Reply-To: References: , , <868F33A7-8F02-4F0B-B8AC-E7748C68622A@cs.purdue.edu>, , <84FF4D41-3DAB-4DF0-92E3-8547DA075582@cs.purdue.edu> Message-ID: Soon we will make the barriers lock free. Right now they lock the heap (blurgh). But we will still need them to be inCritical to prevent GC occurring in the middle of a barrier. On 11 Dec 2009, at 06:44, Jay K wrote: > Btw, I don't understand how all the barriers work so seemingly lock free. > Or maybe they do often take locks? > That is why I don't trust arbitrary invocations of barriers, since I don't know how long > the results stay valid. I really just need to read and internalize this barrier stuff. > > > - Jay > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 11:12:45 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I am very uneasy with this -- it is not a solution... You need to be able to reason about the threads system and how it manipulates traced state. > > On 10 Dec 2009, at 02:43, Jay K wrote: > > I think it is ok now. > Though there is still some mystery, like why did it work before? > There may also still be a race between the extra writes I put and > the "real" uses of traced data. > Maybe I can reduce the traced data. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 10 Dec 2009 06:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] deadlock in Win32 threads? > > Hm. First, what changed is probably the movement of stuff from traced to untraced?? > Which makes it more efficient and more like pthreads. > I might try putting that back. > > > What I have now though, is that in T, Mutex, and Condition, I put an integer field writeToBlahBlah. > Every time before Lock(giant), whatever, t, m, c, I have I write to that field. > That drastically mitigates this problem and it goes away. > > > However that still leaves me with a similar deadlock. > > > This thread is stuck trying to suspend everyone: > > 0:000> ~*k > . 0 Id: a64.1258 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012fd1c 006d033e m3core!RTThread__SuspendOthers+0xdd > 0012fd6c 006d02f0 m3core!RTCollector__CollectSomeInStateZero+0x12 > 0012fd80 006cff87 m3core!RTCollector__CollectSome+0x6e > 0012fdc4 006c817c m3core!RTHeapRep__CollectEnough+0x9b > 0012fe04 006c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 0012fe40 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 0012fe68 0035dc23 m3core!RTHooks__AllocateOpenArray+0x19 > > > This thread is stuck trying to get the heap lock. > It is I presume "inCritical" already. > > > 3 Id: a64.1750 Suspend: 2 Teb: 7ffdb000 Unfrozen > ChildEBP RetAddr > 01c7fb84 7c90df5a ntdll!KiFastSystemCallRet > 01c7fb88 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 01c7fc10 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 01c7fc18 006ed42d ntdll!RtlEnterCriticalSection+0x46 > 01c7fc24 006ec15e m3core!ThreadWin32__Lock+0xd > 01c7fc3c 006c8176 m3core!RTOS__LockHeap+0x2c > 01c7fc7c 006c7d06 m3core!RTAllocator__AllocTraced+0xd1 > 01c7fcb8 006c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01c7fce0 00f8c175 m3core!RTHooks__AllocateOpenArray+0x19 > 01c7fd44 00f8b36e m3ui!WinTrestle__CopyRoots+0x165 > > > The first thread has the heap lock, and isn't giving it up: > > 01ebffec 00000000 kernel32!BaseThreadStart+0x37 > 0:000> ?? m3core!ThreadWin32__heapLock > struct _RTL_CRITICAL_SECTION * 0x00f2b3e0 > +0x00c OwningThread : 0x00001258 > > > Suspending the second thread does work, but it stays inCritical. > I'm guessing at some of this. > > The giant lock is no longer relevant. > > > I don't see why pthreads doesn't behave the same. > > I'll have to read the code more. > > Hm. inCritical maybe shouldn't be set actually? > I'll dig more. > > > - Jay > > > > Subject: Re: [M3devel] deadlock in Win32 threads? > From: hosking at cs.purdue.edu > Date: Wed, 9 Dec 2009 11:13:03 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Jay, you're the one closest to the Win32 threading code these days. Hope you can track it down. > > On 9 Dec 2009, at 09:16, Jay K wrote: > > Win32. > > I have a wierd system..but I think the bug is real. > In particular I was testing a small threading change on head. > How alertable is managed, to remove its write in LockMutex, so I could remove the giant lock there. > But I just had the alertable changes. > > > It was hanging starting Juno. > So I tried to test release. > You can't use head Juno with release m3core...and I didn't rebuild everything. I'll do that. > So I patched up release m3core to be binary compatible. (I'll probably check that in.) > > > Juno still hangs. > > > Here is what I see: > > > 0:006> ~*k This funny thing is like gdb's "thread apply all bt". > ~ is thread; * is all; k is stack. > > [edited] > > > 6 Id: 790.b0 Suspend: 1 Teb: 7ffd7000 Unfrozen > ChildEBP RetAddr > 0234fbe8 7c90df5a ntdll!KiFastSystemCallRet > 0234fbec 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0234fc74 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0234fc7c 006ecb4e ntdll!RtlEnterCriticalSection+0x46 > 0234fc88 006ebd31 m3core!ThreadWin32__EnterCriticalSection_heap+0xe [c:\dev2\cm3 > .release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 30] > 0234fc9c 006d4a51 m3core!RTOS__LockHeap+0x12 [..\src\thread\WIN32\ThreadWin32.m3 > @ 960] > 0234fcd8 006e92b4 m3core!RTHooks__CheckStoreTraced+0x81 [..\src\runtime\common\R > TCollector.m3 @ 2253] > 0234fd0c 00faa995 m3core!ThreadWin32__LockMutex+0xe0 [..\src\thread\WIN32\Thread > Win32.m3 @ 111] > 0234fd30 00fd1fd1 m3ui!VBT__Mark+0x2a [..\src\vbt\VBT.m3 @ 1247] > ... > > > 7 Id: 790.b34 Suspend: 1 Teb: 7ffd6000 Unfrozen > ChildEBP RetAddr > 026dfc5c 7c90df5a ntdll!KiFastSystemCallRet > 026dfc60 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 026dfce8 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 026dfcf0 006ecb2e ntdll!RtlEnterCriticalSection+0x46 > 026dfcfc 006e9c33 m3core!ThreadWin32__EnterCriticalSection_giant+0xe [c:\dev2\cm > 3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\win32\threadwin32c.c @ 29] > 026dfd14 006ec0a1 m3core!Thread__Broadcast+0x12 [..\src\thread\WIN32\ThreadWin32 > .m3 @ 276] > 026dfd30 006d0285 m3core!RTOS__BroadcastHeap+0x55 [..\src\thread\WIN32\ThreadWin > 32.m3 @ 995] > 026dfd44 006d0039 m3core!RTCollector__CollectorOff+0x94 [..\src\runtime\common\R > TCollector.m3 @ 716] > 026dfd64 006cfff4 m3core!RTCollector_M3_LINE_663+0x40 [..\src\runtime\common\RTC > ollector.m3 @ 666] > 026dfda8 006c817c m3core!RTHeapRep__CollectEnough+0x100 [..\src\runtime\common\R > TCollector.m3 @ 671] > 026dfde8 006c7793 m3core!RTAllocator__AllocTraced+0xd7 [..\src\runtime\common\RT > Allocator.m3 @ 364] > 026dfe1c 006c728d m3core!RTAllocator__GetTracedObj+0x8c [..\src\runtime\common\R > TAllocator.m3 @ 222] > 026dfe40 10013797 m3core!RTHooks__AllocateTracedObj+0x15 [..\src\runtime\common\ > RTAllocator.m3 @ 120] > 026dfe7c 1000fde5 juno_compiler!JunoCompileRep__Cmd+0xcf [..\src\JunoCompile.m3 > @ 987] > ... > > > Let's look at two of our important locks: > ?? is the C++ expression evaluator -- the "good" expression evaluator. > > > 0:006> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156b68 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 2 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000b0 > +0x010 LockSemaphore : 0x00000708 > +0x014 SpinCount : 0 > > > 0:006> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x00156ba0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000b34 > +0x010 LockSemaphore : 0x000006ec > +0x014 SpinCount : 0 > > > So you can see there is a circularity and deadlock. > Thread 6 owns giant lock and is waiting for heap lock. > Thread 7 owns heap lock and is waiting for giant lock. > > > This occurs because Win32 LockMutex uses traced references within the giant lock. ? > Use of traced references implies a possible need to take the heap lock. > Doing darn near anything implies a need to use the giant lock. > > > Any ideas Tony? > > > I'm not crazy or have a messed up tree, right? > I mean, now that I've discussed it, the deadlock potential is obviously there, right? > > > Pthreads is safe of course, no giant lock. > > > I was about to remove the giant lock from LockMutex/UnlockMutex. > That should help? > The giant lock would still remain though. > > > Now, we know that condition variables are implementable well enough on Win32. > Either with a giant lock, or how Java does it. > Aside: I don't fully understand the Java implementation, but if it works, it is goodness. > It has no giant lock. I don't understand how the sequence numbers make it work. > > > However the Modula-3 giant lock implementation..I am trusting Birrel here > that it works at ll..doesn't interact well with traced references within its own implementation? > Maybe this stuff can be teased apart? > > > Same thing with a coherent (I think) release build: > > 0:008> ~*k > > 0 Id: f58.d0 Suspend: 1 Teb: 7ffdf000 Unfrozen > ChildEBP RetAddr > 0012f5f4 7c90df5a ntdll!KiFastSystemCallRet > 0012f5f8 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0012f680 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0012f688 005ece7e ntdll!RtlEnterCriticalSection+0x46 > 0012f694 005ec06d m3core!ThreadWin32__EnterCriticalSection_heap+0xe > 0012f6a8 005d4ab1 m3core!RTOS__LockHeap+0x12 > 0012f6e4 005e9434 m3core!RTHooks__CheckStoreTraced+0x81 > 0012f718 00facedc m3core!ThreadWin32__LockMutex+0xe0 > 0012f774 00fb0b51 m3ui!VBTClass__Rescreen+0xed > > ... > > 7 Id: f58.80 Suspend: 1 Teb: 7ffd9000 Unfrozen > ChildEBP RetAddr > 0240fc98 7c90df5a ntdll!KiFastSystemCallRet > 0240fc9c 7c91b24b ntdll!ZwWaitForSingleObject+0xc > 0240fd24 7c901046 ntdll!RtlpWaitForCriticalSection+0x132 > 0240fd2c 005ece5e ntdll!RtlEnterCriticalSection+0x46 > 0240fd38 005e9e6c m3core!ThreadWin32__EnterCriticalSection_giant+0xe > 0240fd50 005ec3dd m3core!Thread__Broadcast+0x12 > 0240fd6c 005d02e5 m3core!RTOS__BroadcastHeap+0x55 > 0240fd80 005d0099 m3core!RTCollector__CollectorOff+0x94 > > > 0:008> ?? m3core!ThreadWin32__giant > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9c0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 5 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x000000d0 > +0x010 LockSemaphore : 0x00000700 > +0x014 SpinCount : 0 > > > 0:008> ?? m3core!ThreadWin32__heap > struct _RTL_CRITICAL_SECTION > +0x000 DebugInfo : 0x7c97e9e0 _RTL_CRITICAL_SECTION_DEBUG > +0x004 LockCount : 1 > +0x008 RecursionCount : 1 > +0x00c OwningThread : 0x00000080 > +0x010 LockSemaphore : 0x000006fc > +0x014 SpinCount : 0 > > > 80 has the heap lock and is trying to get the giant lock > D0 has the giant lock and is trying to get the heap lock > Because of the use of traced references in LockMutex. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:05:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Message-ID: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:09:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:09:37 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:17:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:17:16 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 15:41:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 14:41:53 +0000 Subject: [M3devel] FW: some open bugs In-Reply-To: <4B1C34ED.1E75.00D7.1@scires.com> References: , , <20091125125907.ksf8gu7lgkwsokss@mail.elegosoft.com>, , <4B1C34ED.1E75.00D7.1@scires.com> Message-ID: Sorry no not at this time. I haven't looked in a bit and it stumped me at the time. I think we should either have a build per C runtime version or /maybe/ link to libmt.lib. - Jay >> Can you be more specific about the nature of the "windows C runtime version issue" you report below ? Regards, Randy >>> Jay K 12/6/2009 4:00 AM >>> > https://projects.elego.de/cm3/ticket/1077 > https://projects.elego.de/cm3/ticket/1076 > https://projects.elego.de/cm3/ticket/1068 > https://projects.elego.de/cm3/ticket/1055 > https://projects.elego.de/cm3/ticket/1048 > https://projects.elego.de/cm3/ticket/1056 https://projects.elego.de/cm3/ticket/1077 Windows C runtime version issue -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 15:57:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 09:57:13 -0500 Subject: [M3devel] "port simple race condition fix from head related to stopping a thread before/after it has any traced references" In-Reply-To: References: <20091211111426.0EA142474001@birch.elegosoft.com> Message-ID: <45DB4B67-5013-4A8D-BDEB-8EFE9B08C1F2@cs.purdue.edu> On 11 Dec 2009, at 06:22, Jay K wrote: > Something is fishy here. The change is fine, but there could only be a problem > if suspending the thread didn't work? You know, the stack value shouldn't > be changing? I'm pretty sure I saw this be a problem on some configuration, > but maybe it was only user threads and maybe they are relevantly different? > > Also Tony is it ok to RTHeapRep.FlushThreadState unconditionally here? I think so: only stopped threads have this done to them. If they are using the thread state (for allocation) then they are inCritical. > > - Jay > > > Date: Fri, 11 Dec 2009 12:14:26 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/11 12:14:26 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: > > release_branch_cm3_5_8 > > ThreadPThreadC.c > > > > Log message: > > port simple race condition fix from head related to stopping a thread before/after it has any traced references > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:02:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:02:16 +0000 Subject: [M3devel] Why do we not check stackbase=NIL anymore in ProcessOther? In-Reply-To: <20091211145750.8D48E2474001@birch.elegosoft.com> References: <20091211145750.8D48E2474001@birch.elegosoft.com> Message-ID: I know what I was thinking, but it doesn't make sense any more. I could have sworn I saw a race where the value changed between the check and the subsequent read/use. That makes sense, in that I don't change the value under a lock. But it doesn't make sense, in that the changer should be suspended. The check is done shortly after in the C code though. There is just one read, and the purported race is gone. It should be ok. The one uncertainty on my part is what the HeapRep.FlushState does. I looked at, but I didn't follow through as to the other uses of the state it changes. - Jay > Date: Fri, 11 Dec 2009 15:57:50 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 09/12/11 15:57:50 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Tidy a little. > Why do we not check stackbase=NIL anymore in ProcessOther? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 16:06:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 10:06:03 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: > Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? > > > I'm not sure this is going to work out, but: > I'm "rewriting" stuff to use a separate event for alerting. > alertable goes away > There will be two events: > waitEvent, for condition variables > alertEvent, for alerting > > > roughly speaking: > > > AlertPause: WaitForSingleObject(alertEvent) > AlertWait: > alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) > Alert(t): SetEvent(t.alertEvent); > TestAlert: alerted := WaitForSingleObject(alertEvent, 0); > > > It seems simple enough. > That shows all the ingredients. > That'll eliminate a lot of the global locking. > And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. > You can't just use the Java code because it doesn't include alertability. > You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. > The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:07:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:07:23 +0000 Subject: [M3devel] RTOS.Crash In-Reply-To: <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> References: <20091211114257.4EA062474001@birch.elegosoft.com>, <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> Message-ID: > We should do the same for POSIX too I think. Posix just calls abort. Posix: PROCEDURE Crash () = BEGIN Cstdlib.abort (); LOOP END; (* wait *) END Crash; Win32: PROCEDURE Crash () = CONST Magic = 1 * ADRSIZE (INTEGER); (* == offset of "fp" in this frame *) VAR fp: ADDRESS := ADR (fp) + Magic; (* == my frame pointer *) BEGIN IF WinBase.IsDebuggerPresent () # 0 THEN (* I moved these three lines up. *) WinBase.DebugBreak (); END; RTThread.SuspendOthers (); RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); RTSignal.RestoreHandlers (); (* so we really do crash... *) Exit (-1); END Crash; That said..I'm missing something and I should review the code. Obviously there are calls elsewhere to DumpStack, and they or may not be similarly crufty. /Actually/ one thing I'd like is for the m3core to be able to dump better callstacks. Like, the ability to carry more debuginfo of its own custom format in itself. Like, to get line numbers. - Jay From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:00:35 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 We should do the same for POSIX too I think. On 11 Dec 2009, at 12:42, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/12/11 12:42:57 Modified files: cm3/m3-libs/m3core/src/runtime/WIN32/: Tag: release_branch_cm3_5_8 RTOS.m3 Log message: port from head: very small change that makes debugging sometimes much better (break right into debugger, don't waste time trying to suspend threads and dump stacks, the debugger does a much better job of suspending threads and usually (if you have symbols) of dumping stacks) If you aren't using a debugger, then no change. The thing about RestoreHandlers can probably just be removed since in my brief experience the DebugBreak works fine before it. Really it can probably just go like this: If debugger debugbreak ELSE suspend others, maybe dumpstack one of the important parts restore handlers probably can be removed Exit(-1) also important though maybe should be TerminateProcess which is much quicker/cleaner doesn't run all the dllmains though currently I just made the small change of moving the debugbreak much earlier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:09:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:09:20 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> References: , <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Message-ID: No. I answered my question -- it is in case of really long pauses -- over 4billion milliseconds. The waits are broken up into chunks of that size. We use a 53bit? mantissa longreal to represent seconds whereas Win32 wait is 32bit number of milliseconds. The one doesn't fit in the other. - Jay Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:06:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 16:10:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 10:10:10 -0500 Subject: [M3devel] RTOS.Crash In-Reply-To: References: <20091211114257.4EA062474001@birch.elegosoft.com>, <3A788099-01DB-4DE6-A6D1-4180771C90C7@cs.purdue.edu> Message-ID: <09E070FF-B13F-405F-A6E9-6F73AEEFE680@cs.purdue.edu> OK, cool. On 11 Dec 2009, at 10:07, Jay K wrote: > > We should do the same for POSIX too I think. > > Posix just calls abort. > > Posix: > PROCEDURE Crash () = > BEGIN > Cstdlib.abort (); > LOOP END; (* wait *) > END Crash; > > > Win32: > > > PROCEDURE Crash () = > CONST Magic = 1 * ADRSIZE (INTEGER); (* == offset of "fp" in this frame *) > VAR fp: ADDRESS := ADR (fp) + Magic; (* == my frame pointer *) > BEGIN > IF WinBase.IsDebuggerPresent () # 0 THEN (* I moved these three lines up. *) > WinBase.DebugBreak (); > END; > RTThread.SuspendOthers (); > RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); > RTSignal.RestoreHandlers (); (* so we really do crash... *) > Exit (-1); > END Crash; > > > That said..I'm missing something and I should review the code. > Obviously there are calls elsewhere to DumpStack, and they or may not be similarly crufty. > > > /Actually/ one thing I'd like is for the m3core to be able to dump better callstacks. > Like, the ability to carry more debuginfo of its own custom format in itself. > Like, to get line numbers. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 11 Dec 2009 10:00:35 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > We should do the same for POSIX too I think. > > On 11 Dec 2009, at 12:42, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/11 12:42:57 > > Modified files: > cm3/m3-libs/m3core/src/runtime/WIN32/: Tag: > release_branch_cm3_5_8 > RTOS.m3 > > Log message: > port from head: very small change that makes debugging sometimes much better > (break right into debugger, don't waste time trying to suspend threads > and dump stacks, the debugger does a much better job of suspending > threads and usually (if you have symbols) of dumping stacks) > If you aren't using a debugger, then no change. > > The thing about RestoreHandlers can probably just be removed since > in my brief experience the DebugBreak works fine before it. > > Really it can probably just go like this: > If debugger > debugbreak > ELSE > suspend others, maybe > dumpstack one of the important parts > restore handlers probably can be removed > Exit(-1) also important though maybe should be TerminateProcess which is much quicker/cleaner > doesn't run all the dllmains > > though currently I just made the small change of moving the debugbreak much earlier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 11 16:09:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2009 15:09:44 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> References: , <7422344C-65BA-446D-AA74-133B7E491358@cs.purdue.edu> Message-ID: ps: not to mention the exponent! From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 AlertPause polls instead of one big wait? Date: Fri, 11 Dec 2009 15:09:20 +0000 No. I answered my question -- it is in case of really long pauses -- over 4billion milliseconds. The waits are broken up into chunks of that size. We use a 53bit? mantissa longreal to represent seconds whereas Win32 wait is 32bit number of milliseconds. The one doesn't fit in the other. - Jay Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? From: hosking at cs.purdue.edu Date: Fri, 11 Dec 2009 10:06:03 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Can you get spurious wakeups with those Windows calls? On 11 Dec 2009, at 09:05, Jay K wrote: Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 11 19:12:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Dec 2009 13:12:00 -0500 Subject: [M3devel] Why do we not check stackbase=NIL anymore in ProcessOther? In-Reply-To: References: <20091211145750.8D48E2474001@birch.elegosoft.com> Message-ID: <1884D92B-9409-4AD5-966B-D3E566B7784E@cs.purdue.edu> On 11 Dec 2009, at 10:02, Jay K wrote: > I know what I was thinking, but it doesn't make sense any more. > I could have sworn I saw a race where the value changed between > the check and the subsequent read/use. > That makes sense, in that I don't change the value under a lock. > But it doesn't make sense, in that the changer should be suspended. > The check is done shortly after in the C code though. > There is just one read, and the purported race is gone. > It should be ok. The one uncertainty on my part is what the HeapRep.FlushState does. > I looked at, but I didn't follow through as to the other uses of the state it changes. Ah, yes, I see the test now in the C code. Doesn't make any sense that doing it there should make any difference though. As for the flushing of the heap state, all that is doing is relinquishing the thread's heap allocation context so that GC can occur. > > > - Jay > > > > Date: Fri, 11 Dec 2009 15:57:50 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/12/11 15:57:50 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > > > Log message: > > Tidy a little. > > Why do we not check stackbase=NIL anymore in ProcessOther? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sat Dec 12 05:50:57 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 11 Dec 2009 23:50:57 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: Message-ID: <4B22D975.1E75.00D7.1@scires.com> Jay, I notice you say something about Win9x below. I never had much success with Win9x back in the cm3 v4.1 days. Farshad and company stated that they would only support WindowsNT4.0 back then. I think it would be fine at this point to just support the newer stuff (Windows NT4.0 / 2000 / XP / Vista / Windows 7) and not worry about the old 9x versions or even NT3.5. I've been watching all the activity on threading and mutexes. I keep updating from the HEAD branch and rebuilding on XP and Vista to make sure stuff still compiles. I must admit all these low-level changes concern me for the same reasons Olaf outlined a few days ago. I've not had much time to devote to cm3 lately, but I will try to test using some of my multi-threaded programs as soon as I can. However, I fear it will be hard to tell if something is only "slightly broken" or "slightly misbehaves" because unless you see a crash or obvious behavior flaw, you won't know it is "slightly" broken. I did contribute a "Mutex Checker" test program a few weeks back. I'll keep running it, but it doesn't test all the alert and condition variable stuff. I think we need some test programs that can prove correctness, but these are going to be hard to develop I fear. Regards, Randy >>> Jay K 12/11/2009 9:17 AM >>> [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 06:37:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 05:37:44 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: <4B22D975.1E75.00D7.1@scires.com> References: , , <4B22D975.1E75.00D7.1@scires.com> Message-ID: Randy, I was just going to ask about this..: building with Visual C++ 2.0 (banner says copyright 1994): Time.mo : error LNK2001: unresolved external symbol "_GetSystemTimeAsFileTime at 4" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_GetIcon at 12" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_LoadImageA at 28" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_Remove at 8" WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_ReplaceIcon at 12" ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange" ThreadWin32.mo : error LNK2001: unresolved external symbol "_InterlockedCompareExchange at 12" RTOS.mo : error LNK2001: unresolved external symbol "_IsDebuggerPresent at 0" m3core.dll : error LNK1120: 8 unresolved externals building with Visual C++ 4.0 (circa 1996?): ThreadWin32.mo : error LNK2001: unresolved external symbol _InterlockedCompareExchange at 12 ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange m3core.dll : fatal error LNK1120: 2 unresolved externals building with Visual C++ 4.2 (circa 1996?): works Which is also some significant measure of what operating systems work. I had deleted \cm3\lib. If you build in m3-win\import-libs, then the problems drop to just InterlockedCompareExchange, and that is easily fixed. Though again it is a measure of what operating system versions will work. I'm really undecided here. Our dependency on anything beyond Windows 95/NT 3.1, maybe even Win32s, is really slight or nonexistant. If you look at the above list for example, InterlockedCompareExchange I /just/ introduced to replace a lock, a lock that I had only introduced recently as part of removing the giant lock (the lock is much smaller). IsDebuggerPresent is really optional. GetSystemTimeAsFileTime is trivial to do without. ImageList stuff probably isn't needed -- we certainly get stuff at the wrong layer because of a certain part of our architecture. You know, normally in C / C++, there's no comctl32.dll support at any lower level, whoever needs it just #includes commctl.h. It is our "wrappers" that introduce this dependency. The way I discover the stack boundaries might not work on Win9x/Win32s, but it might. For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007. If all that works, things are better than they were for a long time. For many months Juno would sometimes hang due to a bug that affected all programs. Granted, we didn't necessarily ever release that bug. In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD. For better and for worse, these parts of the system do need work imho. My changes are also mostly for the simpler. Of course nobody can decide what is "simple". The change to remove the giant lock from LockMutex/UnlockMutex agrees with Birrel's paper, which only implies the lock might be there for an optimization elsewhere, an optimization that we didn't have. Let me know of any slight or suspected problem and esp. let me run the code. We should be ok, or better. :) For the alert thing we could do a version check and/or GetProcAddress on QueueUserAPC, or actually I suspect it is easy to be Win9x compatible. You'd have each thread open/create its own anonymous pipe and to alert the thread you'd just write a byte the pipe. I could test older systems in VMs. I mostly just use XP. - Jay Date: Fri, 11 Dec 2009 23:50:57 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait? Jay, I notice you say something about Win9x below. I never had much success with Win9x back in the cm3 v4.1 days. Farshad and company stated that they would only support WindowsNT4.0 back then. I think it would be fine at this point to just support the newer stuff (Windows NT4.0 / 2000 / XP / Vista / Windows 7) and not worry about the old 9x versions or even NT3.5. I've been watching all the activity on threading and mutexes. I keep updating from the HEAD branch and rebuilding on XP and Vista to make sure stuff still compiles. I must admit all these low-level changes concern me for the same reasons Olaf outlined a few days ago. I've not had much time to devote to cm3 lately, but I will try to test using some of my multi-threaded programs as soon as I can. However, I fear it will be hard to tell if something is only "slightly broken" or "slightly misbehaves" because unless you see a crash or obvious behavior flaw, you won't know it is "slightly" broken. I did contribute a "Mutex Checker" test program a few weeks back. I'll keep running it, but it doesn't test all the alert and condition variable stuff. I think we need some test programs that can prove correctness, but these are going to be hard to develop I fear. Regards, Randy >>> Jay K 12/11/2009 9:17 AM >>> [was truncated..] Oh -- it is so you can wait for more than 4 billion milliseconds, I guess. The chunk size of the loop is roughly the maximum time WaitForSingleObject is allowed. Ok. btw, we could also use Win32's native "alert" mechanism. That would save creating all the alert events. The downside is that I don't see how to alert a wait on Win9x. Maybe via some extra arbitrary async pipe i/o? On NT it's just QueueUserAPC. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 11 Dec 2009 14:05:56 +0000 Subject: [M3devel] win32 AlertPause polls instead of one big wait? Anyone know why Win32 AlertPause uses a polling loop instead of just one wait? I'm not sure this is going to work out, but: I'm "rewriting" stuff to use a separate event for alerting. alertable goes away There will be two events: waitEvent, for condition variables alertEvent, for alerting roughly speaking: AlertPause: WaitForSingleObject(alertEvent) AlertWait: alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0) Alert(t): SetEvent(t.alertEvent); TestAlert: alerted := WaitForSingleObject(alertEvent, 0); It seems simple enough. That shows all the ingredients. That'll eliminate a lot of the global locking. And then one "last" iteration to use the Java code for condition variables and the global lock will be gone. You can't just use the Java code because it doesn't include alertability. You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex. The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 12 06:59:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Dec 2009 00:59:03 -0500 Subject: [M3devel] win32 AlertPause polls instead of one big wait? In-Reply-To: References: , , <4B22D975.1E75.00D7.1@scires.com> Message-ID: FreeBSD pthreads has not previously been supported. Just Linux, Solaris, OSX. On 12 Dec 2009, at 00:37, Jay K wrote: > > Randy, I was just going to ask about this..: > > > > > > building with Visual C++ 2.0 (banner says copyright 1994): > > Time.mo : error LNK2001: unresolved external symbol "_GetSystemTimeAsFileTime at 4" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_GetIcon at 12" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_LoadImageA at 28" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_Remove at 8" > WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_ReplaceIcon at 12" > ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange" > ThreadWin32.mo : error LNK2001: unresolved external symbol "_InterlockedCompareExchange at 12" > RTOS.mo : error LNK2001: unresolved external symbol "_IsDebuggerPresent at 0" > m3core.dll : error LNK1120: 8 unresolved externals > > > > building with Visual C++ 4.0 (circa 1996?): > ThreadWin32.mo : error LNK2001: unresolved external symbol _InterlockedCompareExchange at 12 > ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange > m3core.dll : fatal error LNK1120: 2 unresolved externals > > > > building with Visual C++ 4.2 (circa 1996?): > works > > > > Which is also some significant measure of what operating systems work. > > I had deleted \cm3\lib. If you build in m3-win\import-libs, then the problems drop to just InterlockedCompareExchange, and that is easily fixed. Though again it is a measure of what operating system versions will work. > > > > > > I'm really undecided here. Our dependency on anything beyond Windows 95/NT 3.1, maybe even Win32s, is really slight or nonexistant. If you look at the above list for example, InterlockedCompareExchange I /just/ introduced to replace a lock, a lock that I had only introduced recently as part of removing the giant lock (the lock is much smaller). IsDebuggerPresent is really optional. GetSystemTimeAsFileTime is trivial to do without. ImageList stuff probably isn't needed -- we certainly get stuff at the wrong layer because of a certain part of our architecture. You know, normally in C / C++, there's no comctl32.dll support at any lower level, whoever needs it just #includes commctl.h. It is our "wrappers" that introduce this dependency. > > The way I discover the stack boundaries might not work on Win9x/Win32s, but it might. > > > > > > For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007. > > If all that works, things are better than they were for a long time. > > For many months Juno would sometimes hang due to a bug that affected all programs. > > Granted, we didn't necessarily ever release that bug. > > In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD. > > For better and for worse, these parts of the system do need work imho. > > > > > > My changes are also mostly for the simpler. Of course nobody can decide what is "simple". > > The change to remove the giant lock from LockMutex/UnlockMutex agrees with Birrel's paper, which only implies the lock might be there for an optimization elsewhere, an optimization that we didn't have. > > Let me know of any slight or suspected problem and esp. let me run the code -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 07:47:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 06:47:28 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? Message-ID: cloning headers vs. indirection/win32 So..I've been a champion of pushing code into C to avoid cloning headers. I'm not sure the following statement is logical: It is easier to clone "windows.h" than "libc.h". The possible logic is that there is less variation. There is very little #ifdef in windows.h, whereas "libc.h" contains both #ifdefs and there are to some extent n different versions. Another possible explanation is that windows.h was cloned long ago not by me and "libc.h" I've had to deal with more, on "new" systems. It is an exaggeration to say OpenBSD/NetBSD/FreeBSD/Linux/Solaris/Darwin etc. are "completely" different independent rewrites but it is also an exaggeration to say they are "the same". It is tempting to say the stat struct is the only problem, but it isn't. If it IS logical, then some of this could/should be undone for Windows. In particular I'm pretty sympathetic to having the Modula-3 code use Initialize/Enter/LeaveCriticalSection directly. With the following caveats: - maybe it isn't logical - as things are currently, there is more opportunity to merge pthreads and Win32 implementation Going "back" to a somewhat more optimized Win32 implementation is a bit of a barrier to merging them. I'll probably things asis in this regard. You know..to be "consistent", I should go through ThreadWin32.m3's: FROM WinNT IMPORT LONG, HANDLE, DWORD, UINT32; FROM WinBase IMPORT WaitForSingleObject, INFINITE, CloseHandle, CreateThread, ResumeThread, Sleep, SuspendThread, GetThreadContext, SetLastError, GetLastError, CREATE_SUSPENDED, GetCurrentThreadId, InterlockedCompareExchange, InterlockedExchange, InterlockedIncrement, InterlockedDecrement, SetEvent, WAIT_OBJECT_0, CreateEvent, WaitForMultipleObjects; FROM ThreadContext IMPORT PCONTEXT; and reduce those and/or wrap them in C like is done for m3core/unix. Well, maybe. Constants are easy, plus statically link a la hand.obj/Uconstants.obj. Functions are easy. "base" types like LONG, HANDLE, DWORD, UINT32 we just go ahead and clone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 08:27:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 07:27:33 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? In-Reply-To: References: Message-ID: Actually it appears the indirection is needed for CRITICAL_SECTION. WinNT.i3: (* NOTE: "PRTL_CRITICAL_SECTION" is declared as a Modula-3 opaque type and then immediately revealed so that "EnterCriticalSection()" and "LeaveCriticalSection()" won't require checks by the GC wrapper routines. Clearly, if a Windows critical section is inside an M3 traced ref (which moves!) the system is going to crash. Hence, the extra GC check isn't needed. *) TYPE PRTL_CRITICAL_SECTION <: ADDRESS; REVEAL PRTL_CRITICAL_SECTION = UNTRACED BRANDED "WinNT.PRTL_CRITICAL_SECTION" REF RTL_CRITICAL_SECTION; But we could still have the global locks (slotLock, activeLock, initLock, perfLock etc.) be "direct" CRITICAL_SECTIONS and just the "dynamic" ones (Thread.Mutex) have the indirection. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sat, 12 Dec 2009 06:47:28 +0000 Subject: [M3devel] cloning headers vs. indirection/win32? cloning headers vs. indirection/win32 So..I've been a champion of pushing code into C to avoid cloning headers. I'm not sure the following statement is logical: It is easier to clone "windows.h" than "libc.h". The possible logic is that there is less variation. There is very little #ifdef in windows.h, whereas "libc.h" contains both #ifdefs and there are to some extent n different versions. Another possible explanation is that windows.h was cloned long ago not by me and "libc.h" I've had to deal with more, on "new" systems. It is an exaggeration to say OpenBSD/NetBSD/FreeBSD/Linux/Solaris/Darwin etc. are "completely" different independent rewrites but it is also an exaggeration to say they are "the same". It is tempting to say the stat struct is the only problem, but it isn't. If it IS logical, then some of this could/should be undone for Windows. In particular I'm pretty sympathetic to having the Modula-3 code use Initialize/Enter/LeaveCriticalSection directly. With the following caveats: - maybe it isn't logical - as things are currently, there is more opportunity to merge pthreads and Win32 implementation Going "back" to a somewhat more optimized Win32 implementation is a bit of a barrier to merging them. I'll probably things asis in this regard. You know..to be "consistent", I should go through ThreadWin32.m3's: FROM WinNT IMPORT LONG, HANDLE, DWORD, UINT32; FROM WinBase IMPORT WaitForSingleObject, INFINITE, CloseHandle, CreateThread, ResumeThread, Sleep, SuspendThread, GetThreadContext, SetLastError, GetLastError, CREATE_SUSPENDED, GetCurrentThreadId, InterlockedCompareExchange, InterlockedExchange, InterlockedIncrement, InterlockedDecrement, SetEvent, WAIT_OBJECT_0, CreateEvent, WaitForMultipleObjects; FROM ThreadContext IMPORT PCONTEXT; and reduce those and/or wrap them in C like is done for m3core/unix. Well, maybe. Constants are easy, plus statically link a la hand.obj/Uconstants.obj. Functions are easy. "base" types like LONG, HANDLE, DWORD, UINT32 we just go ahead and clone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 12 16:25:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Dec 2009 15:25:44 +0000 Subject: [M3devel] to share code between Join and AlertJoin or not? Message-ID: Here's a case where it is not clear if the code is worth sharing: Join and AlertJoin share XJoin: PROCEDURE XJoin (t: T; alertable: BOOLEAN): REFANY RAISES {Alerted} = VAR (* The order of the handles is important. *) handles := ARRAY [0..1] OF HANDLE {t.act.handle, NIL(*alertEvent*)}; wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; IF alertable THEN handles[1] := GetActivation().alertEvent; END; wait := WaitForMultipleObjects(1 + ORD(alertable), ADR(handles[0]), 0, INFINITE); <* ASSERT wait # WAIT_TIMEOUT *> <* ASSERT wait = WAIT_OBJECT_0 OR wait = (WAIT_OBJECT_0 + 1) *> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT wait = WAIT_OBJECT_0 + 1 *> <* ASSERT alertable *> RAISE Alerted; END; END XJoin; PROCEDURE Join(t: T): REFANY = <*FATAL Alerted*> BEGIN IF DEBUG THEN ThreadDebug.Join(t); END; RETURN XJoin(t, alertable := FALSE); END Join; PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} = BEGIN IF DEBUG THEN ThreadDebug.AlertJoin(t); END; RETURN XJoin(t, alertable := TRUE); END AlertJoin; OR without code sharing, it'd go like: PROCEDURE Join(t: T): REFANY = VAR wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForSingleObject(t.act.handle, INFINITE); <* ASSERT wait = WAIT_OBJECT_0 *> t.joined := 1; RETURN t.result; END Join; PROCEDURE AlertJoin (t: T): REFANY RAISES {Alerted} = VAR (* The order of the handles is important. *) handles := ARRAY [0..1] OF HANDLE {t.act.handle, GetActivation().alertEvent}; wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForMultipleObjects(2, ADR(handles[0]), 0, INFINITE); <* ASSERT wait # WAIT_TIMEOUT *> <* ASSERT wait = WAIT_OBJECT_0 OR wait = (WAIT_OBJECT_0 + 1) *> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT wait = WAIT_OBJECT_0 + 1 *> RAISE Alerted; END; END AlertJoin; anyone have strong feelings either way? If we used win32 alertable waits, then the case for code sharing would be stronger, it'd go like: PROCEDURE XJoin (t: T; alertable: BOOLEAN): REFANY RAISES {Alerted} = VAR wait: DWORD; BEGIN IF t.joined # 0 THEN Die(ThisLine(), "attempt to join with thread twice") END; wait := WaitForSingleObjectEx(t.act.handle, INFINITE, ORD(alertable)); <* ASSERT wait = WAIT_OBJECT_0 OR wait = WAIT_IO_COMPLETION*> IF wait = WAIT_OBJECT_0 THEN t.joined := 1; RETURN t.result; ELSE <* ASSERT alertable *> RAISE Alerted; END; END XJoin; - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 01:37:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 00:37:43 +0000 Subject: [M3devel] AlertPause(0) is alertable? Message-ID: If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 04:41:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091213033734.E108E2474002@birch.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> Message-ID: 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 04:46:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 03:46:57 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 05:56:08 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 12 Dec 2009 23:56:08 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: Message-ID: <4B242C23.1E75.00D7.1@scires.com> My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 05:56:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 04:56:18 +0000 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: <4B242C23.1E75.00D7.1@scires.com> References: , <4B242C23.1E75.00D7.1@scires.com> Message-ID: Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:02:34 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:02:34 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com> Message-ID: <4B242DA5.1E75.00D7.1@scires.com> Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:04:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:04:43 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242DA5.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com> Message-ID: Randy, ok, thanks it sounds like you did one of the two things. 1) Remerge old diffs to new tree. but not 2) Lift out what is common into a common file, instead of forking the entire file. I didn't mean to imply Unix gui should look like Windows gui. Just that the large amounts of common code should not be duplicated. Probably what'd work is have one merged file with some if's sprinkled. I think what Unix gui should look like is a perpetually unsolved problem and the answer is somewhere between "terrible" and "like Windows", with KDE at least near the second extreme. :) Trestle seems to be among the uglier Unix gui libraries actually.. It'd be nice if there was an option to adapt to the current "theme", but Trestle to me is a very large unknown.. - Jay Date: Sun, 13 Dec 2009 00:02:34 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:12:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:12:21 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: <4B242FF0.1E75.00D7.1@scires.com> Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:16:31 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:16:31 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: , <4B242C23.1E75.00D7.1@scires.com> Message-ID: <4B2430EA.1E75.00D7.1@scires.com> Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. Regards, Randy >>> Jay K 12/12/2009 11:56 PM >>> Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:13:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:13:09 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:15:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:15:49 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: [pesky truncation again!] From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] FW: Win32/ScrollerVBTClass.m3 Date: Sun, 13 Dec 2009 05:13:09 +0000 Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:22:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:22:25 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com> Message-ID: <4B24324C.1E75.00D7.1@scires.com> Jay: You are correct that I did not attempt to factor out common code. At the time, we were more interested in correct behavior, and such factoring did not provide any benefits to the executing code. The benefit of such factoring is in reducing the source tree size and potentially improved maintainability, if done right. So to that end, I applaud your efforts. Regards, Randy >>> Jay K 12/13/2009 12:04 AM >>> Randy, ok, thanks it sounds like you did one of the two things. 1) Remerge old diffs to new tree. but not 2) Lift out what is common into a common file, instead of forking the entire file. I didn't mean to imply Unix gui should look like Windows gui. Just that the large amounts of common code should not be duplicated. Probably what'd work is have one merged file with some if's sprinkled. I think what Unix gui should look like is a perpetually unsolved problem and the answer is somewhere between "terrible" and "like Windows", with KDE at least near the second extreme. :) Trestle seems to be among the uglier Unix gui libraries actually.. It'd be nice if there was an option to adapt to the current "theme", but Trestle to me is a very large unknown.. - Jay Date: Sun, 13 Dec 2009 00:02:34 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:37:55 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:37:55 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <4B2435EE.1E75.00D7.1@scires.com> Jay: My recollection is that I had multiple source trees to work with, including the then current repository, my original 4.1 source tree, and the modified 4.1 source tree we got from Farshad. There may have been others; I don't remember; its been a while. I also vaguely recall doing some comparisons against the DEC SRC sources, which I also had. I never used mentor, so I can't comment there. As far as whether Modula-3 is still ahead of its time, I think the work we are all doing is necessary if the language is to survive. Right now, I think we are playing catch up in terms of having viable implementations on a sufficient base of modern OS and processors. I still prefer Modula-3 as a language and I think it has a lot to offer. >From an educational standpoint, I can't think of a better language for one to learn good programming principles and practices. Perhaps if more computer science students started out with Modula-3 the world would be a better place... Back when Microsoft first came out with .NET, I seriously considered working on a Modula-3 implementation for .NET and talked with some folks at Microsoft about it, but my career and family kept me busy and I never got very far. Regards, Randy >>> Jay K 12/13/2009 12:13 AM >>> Randy, I get the feeling that Modula-3 was ahead of its time..but is it still? I wasn't complaining that it took you 11 years, just that you'd have to be careful merging in such old stuff. It's possible the other fork had changed a lot..though it appears it hadn't. Were you given the common base -- the unmodified file this was derived from -- or just left to diff it against 3.6 or 4.1? Do you know by chance if mentor worked or when it did? I was going to test RC2/3/4 here, but 1) some of the links are broken 2) even if they weren't, there's no "all" package to download, inconvenient. I rather suspect they are all broken here. But it could be "timing related" -- like, depend on when things appear on the screen or something..not sure what was NIL but I kind of suspect it might follow from things not displaying yet. Again the posix and win32 code appears largely the same. Maybe the two files could be merged in order to share the parts that are in fact the same? Giving us maybe less code to maintain? I know, it can go both ways. Sometimes in order to "merge" somewhat different code you have to "mess it up" with confusing "ifs", where splitting into two can lead to simpler code. It depends on the exact code and is subjective. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:34:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:34:21 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? Message-ID: https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:38:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:38:46 +0000 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: <4B2430EA.1E75.00D7.1@scires.com> References: , , <4B242C23.1E75.00D7.1@scires.com>, , <4B2430EA.1E75.00D7.1@scires.com> Message-ID: The 4.1 code has the bug (this is probably identical but I haven't done a mechanical diff, but it is plain to see it has the bug): (I bought 4.1 too). PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1000.0D0)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; - Jay Date: Sun, 13 Dec 2009 00:16:31 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. Regards, Randy >>> Jay K 12/12/2009 11:56 PM >>> Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. Note that the 3.6 code doesn't seem to get it right: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; The 3.6 and current user threads code seems ok, but I've not very familiar with it. This might be one of those things though that's been consistently broken for so long that it's best not to depend on? Prefer AlertPause(0.01) over AlertPause(0)?? - Jay Date: Sat, 12 Dec 2009 23:56:08 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] AlertPause(0) is alertable? My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. Regards, Randy >>> Jay K 12/12/2009 7:37 PM >>> If I call AlertPause with <= 0 time, should I recieve alerts? Current pthread/win32 implementations: no. They say if time <= then return end before doing much. My suspicion: yes. Thread.i3: PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; (* Like "Pause", but if the thread is marked alerted at the time of the call or sometime during the wait, raise "Alerted". *) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:42:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:42:19 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: Message-ID: I seem to have quite a knack for placing periods in column 76 by accident. This was truncated right at the end. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 13 Dec 2009 05:34:21 +0000 > Subject: [M3devel] pickle bug..solved?.. not supposed to work? > > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Dec 13 06:52:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 13 Dec 2009 00:52:53 -0500 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: Message-ID: <4B243970.1E75.00D7.1@scires.com> Jay: I've done a lot with Pickles and with NetObj. I switched to the v2 version a long time ago and never looked back. IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. Regards, Randy >>> Jay K 12/13/2009 12:34 AM >>> https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:47:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:47:29 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242FF0.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: I keep trying to understand Trestle but I keep failing. I tried to read the comments explaining how its locking works and I got lost quickly. I suspect that compares well to other GUI libraries in that they probably just don't do threading well. Easy to understand though. The Trestle apps are all pretty ugly and oddly behaved. Granted, I have no "real use" for them. I just exercise them a bit as test cases. I did notice you made the scrollbars look "nice" on Windows. The close box is marked "C". The grow box is marked "G". Yuck. As I said though, the more I look into Trestle, the more I think it is implementing a rather complete "windows system" and not just a library of widgets, nor even widgets + resizing algorithms. Nor even just widgets + resizing + event routing. Like, it seems to also manage clipping, knowing what needs redrawing, etc. But I'm not sure. It adds up to a lot of code, is my concern. That is good and bad. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 13 06:50:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Dec 2009 05:50:59 +0000 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <4B243970.1E75.00D7.1@scires.com> References: , <4B243970.1E75.00D7.1@scires.com> Message-ID: I assume there is a need to keep the code around for compatibility? You know -- to read existing files? And to keep testing that? And write them at least so the tests can read them back? But maybe we should take a read-only attitude? And switch the quake netobj=netobj1 to netobj=netobj2? It's tough..if you convert-upon-write, and people are running old programs, you'll break their files. It's also tough, you know, I think this stuff is too automatic. I'm pretty sure we should change the Text internal representation, but I'm also pretty sure the persistance (disk) representation is automatically derived from the transient (memory) representation and changing the second breaks the first. You know, I suspect it is like those systems that do: struct foo a; fwrite(&a, sizeof(a)); but just with endian/wordsize conversions and hashes/typeid to do checks upon read, so it won't crash if you change things, but it also won't read back successfully. Maybe the v1 limitations are good as well, in that maybe it is faster, and sometimes the limitations don't matter??? - Jay Date: Sun, 13 Dec 2009 00:52:53 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? Jay: I've done a lot with Pickles and with NetObj. I switched to the v2 version a long time ago and never looked back. IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. Regards, Randy >>> Jay K 12/13/2009 12:34 AM >>> https://projects.elego.de/cm3/ticket/1068 I've only spent a few minutes here. Trying to find the relative code and such. The code is here: C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src I found it by looking near the top of the stack in the bug report -- NetObjTest.m3 -- and then dir /s/b NetObjTest.m3. or find . | grep NetObjTest.m3$ on Unix. It appears that Pickle v1 and v2 are both available in the same library. There is INTERFACE Pickle and INTERFACE Pickle2. It appears netobj can use either. If you look at the stack in the bug, there is a lot of "v1" stuff. We provide Quake functions: readonly proc netobjv1(intf, type) is ... end readonly proc Netobjv1(intf, type) is ... end readonly proc netobjv2(intf, type) is ... end readonly proc netobj(intf, type) is netobjv1(intf, type) end v1 pickles cannot cross endian/wordsize boundaries. I think the bug is not so much in the pickle code, nor in the netobj code, but in the test code, or the running of it. Tests involving v1 won't work crossing endian/wordsize boundaries. V1 tests probably should still run, and maybe detect the mismatch and just claim success? And then v2 should get better coverage? Any more bugs then? I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:10:40 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:10:40 -0500 Subject: [M3devel] AlertPause(0) is alertable? In-Reply-To: References: , , <4B242C23.1E75.00D7.1@scires.com>, , <4B2430EA.1E75.00D7.1@scires.com> Message-ID: <751737BC-0080-4F0C-975E-11C17246937F@cs.purdue.edu> Given that I based pthreads on win32 its no surprise that I replicated the bug. I've fixed it in ThreadPThread on the trunk. Probably needs copying over to the release branch. On 13 Dec 2009, at 00:38, Jay K wrote: > The 4.1 code has the bug (this is probably identical but I haven't done a mechanical diff, > but it is plain to see it has the bug): > (I bought 4.1 too). > > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = > VAR amount, thisTime: LONGREAL; > CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; > VAR self: T; > BEGIN > self := Self(); > amount := n; > WHILE amount > 0.0D0 DO > thisTime := MIN (Limit, amount); > amount := amount - thisTime; > WinBase.EnterCriticalSection(cm); > InnerTestAlert(self); > self.alertable := TRUE; > <* ASSERT(self.waitingOn = NIL) *> > WinBase.LeaveCriticalSection(cm); > EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1000.0D0)); > WinBase.EnterCriticalSection(cm); > self.alertable := FALSE; > IF self.alerted THEN > (* Sadly, the alert might have happened after we timed out on the > semaphore and before we entered "cm". In that case, we need to > decrement the semaphore's count *) > EVAL WinBase.WaitForSingleObject(self.waitSema, 0); > InnerTestAlert(self); > END; > WinBase.LeaveCriticalSection(cm); > END; > END AlertPause; > > - Jay > > > > Date: Sun, 13 Dec 2009 00:16:31 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] AlertPause(0) is alertable? > > Jay: I never messed around much with the 3.6 code. I purchased the 4.1 commercial version. Prior to that we did use the DEC SRC version and that would have been the extent of my 3.6 familiarity. After the commercial release came out, we went exclusively with Critical Mass 4.1. > Regards, > Randy > > >>> Jay K 12/12/2009 11:56 PM >>> > Randy, Thanks. I fixed Win32 to be like that. pthreads still looks wrong. > > > Note that the 3.6 code doesn't seem to get it right: > > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = > VAR amount, thisTime: LONGREAL; > CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; > VAR self: T; > BEGIN > self := Self(); > amount := n; > WHILE amount > 0.0D0 DO > thisTime := MIN (Limit, amount); > amount := amount - thisTime; > WinBase.EnterCriticalSection(cm); > InnerTestAlert(self); > self.alertable := TRUE; > <* ASSERT(self.waitingOn = NIL) *> > WinBase.LeaveCriticalSection(cm); > EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); > WinBase.EnterCriticalSection(cm); > self.alertable := FALSE; > IF self.alerted THEN > (* Sadly, the alert might have happened after we timed out on the > semaphore and before we entered "cm". In that case, we need to > decrement the semaphore's count *) > EVAL WinBase.WaitForSingleObject(self.waitSema, 0); > InnerTestAlert(self); > END; > WinBase.LeaveCriticalSection(cm); > END; > END AlertPause; > > The 3.6 and current user threads code seems ok, but I've not very familiar with it. > > This might be one of those things though that's been consistently broken for so long that it's best not to depend on? > Prefer AlertPause(0.01) over AlertPause(0)?? > > > - Jay > > > > Date: Sat, 12 Dec 2009 23:56:08 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] AlertPause(0) is alertable? > > My understanding of the interface has always been as you suggest, namely, yes you should get an "Alerted" exception if the thread is marked alerted regardless of the value of the n (seconds) parameter. > > Regards, > Randy > > >>> Jay K 12/12/2009 7:37 PM >>> > If I call AlertPause with <= 0 time, should I recieve alerts? > Current pthread/win32 implementations: no. > They say if time <= then return end before doing much. > My suspicion: yes. > > > Thread.i3: > > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted}; > (* Like "Pause", but if the thread is marked alerted at the time of > the call or sometime during the wait, raise "Alerted". *) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:11:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:11:44 -0500 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: References: , <4B243970.1E75.00D7.1@scires.com> Message-ID: <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> Yes, v1 is there in case anyone has v1 pickles they want to decode. On 13 Dec 2009, at 00:50, Jay K wrote: > I assume there is a need to keep the code around for compatibility? > You know -- to read existing files? > And to keep testing that? > And write them at least so the tests can read them back? > > > But maybe we should take a read-only attitude? > > > And switch the quake netobj=netobj1 to netobj=netobj2? > > > It's tough..if you convert-upon-write, and people are > running old programs, you'll break their files. > > > It's also tough, you know, I think this stuff is too automatic. > I'm pretty sure we should change the Text internal representation, > but I'm also pretty sure the persistance (disk) representation > is automatically derived from the transient (memory) > representation and changing the second breaks the first. > > > You know, I suspect it is like those systems > that do: > > > struct foo a; > fwrite(&a, sizeof(a)); > > > but just with endian/wordsize conversions and > hashes/typeid to do checks upon read, so it > won't crash if you change things, but it also won't > read back successfully. > > > Maybe the v1 limitations are good as well, in that maybe > it is faster, and sometimes the limitations don't matter??? > > > - Jay > > > Date: Sun, 13 Dec 2009 00:52:53 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? > > Jay: > > I've done a lot with Pickles and with NetObj. > > I switched to the v2 version a long time ago and never looked back. > > IMO, we should switch over to v2 exclusively and consider v1 obsolete. Perhaps some others should comment on this to see if they share my opinion. > > Regards, > Randy > > >>> Jay K 12/13/2009 12:34 AM >>> > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with pickles -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Dec 13 19:09:57 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 13 Dec 2009 12:09:57 -0600 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <4B243970.1E75.00D7.1@scires.com> References: <4B243970.1E75.00D7.1@scires.com> Message-ID: <4B252DF5.7020400@lcwb.coop> Randy Coleburn wrote: > Jay: > > I've done a lot with Pickles and with NetObj. > > I switched to the v2 version a long time ago and never looked back. > > IMO, we should switch over to v2 exclusively and consider v1 > obsolete. Perhaps some others should comment on this to see if they > share my opinion. I am using pickles and have done work inside pickle code. I agree strongly on this. V2 pickle code can read pickle files written by V1 pickle code (or at least V2 pickles have code that appears to do so), so old pickle files can still be read. This adaptation is made at dynamically at read time by looking at the pickle file header, so no user action is required. So there is really no benefit to using V1 pickle code. There is one thing that has been a problem for me in the past. In PM3, importing "Pickle" gets you version 2, while in CM3, "Pickle" gets you V1 and you have to import "Pickle2" to get V2. This means code that is to compile/run in either PM3 or CM3 has to have changes to actual source code. I have scripted this, but it is a messy and fragile kludge. I will probably drop maintaining PM3/CM3 compilability in the future. Anybody else doing this? There is one other messy problem that comes to mind. Both versions have a few hard-coded signatures for a few language-predefined types that do not consistently follow the byte order used in type signatures in general. They differ both between the versions and from the general rule. In some case(s), the byte ordering used is downright bizarre. I don't remember for certain, but I think I fixed V2 to adapt to V1's conventions on this when reading V1 pickle files. > > Regards, > Randy > > >>> Jay K 12/13/2009 12:34 AM >>> > > https://projects.elego.de/cm3/ticket/1068 > > > > > > I've only spent a few minutes here. > > Trying to find the relative code and such. > > > > > > The code is here: > > > > > > C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src > > > > I found it by looking near the top of the stack in > > the bug report -- NetObjTest.m3 -- and > > then dir /s/b NetObjTest.m3. > > > > or find . | grep NetObjTest.m3$ on Unix. > > > > > > It appears that Pickle v1 and v2 are both > > available in the same library. > > There is INTERFACE Pickle and INTERFACE Pickle2. > > > > > > It appears netobj can use either. > > > > If you look at the stack in the bug, there is a lot of "v1" stuff. > > > > > > We provide Quake functions: > > > > readonly proc netobjv1(intf, type) is > ... > > end > > > > readonly proc Netobjv1(intf, type) is > ... > > end > > > > readonly proc netobjv2(intf, type) is > ... > > end > > > > readonly proc netobj(intf, type) is > netobjv1(intf, type) > end > > > > > > > v1 pickles cannot cross endian/wordsize boundaries. > > > > > > I think the bug is not so much in the pickle code, nor in the netobj code, > > but in the test code, or the running of it. > > > > Tests involving v1 won't work crossing endian/wordsize boundaries. > > V1 tests probably should still run, and maybe detect the mismatch > > and just claim success? > > > > And then v2 should get better coverage? > > > > > > Any more bugs then? > > I was procrastinating on this because I've never done anything with > pickles From hosking at cs.purdue.edu Sun Dec 13 19:28:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:28:23 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, Message-ID: <75934296-836C-4024-B61B-1321002FB567@cs.purdue.edu> Trestle is of historic interest to the M3 community. We should try to keep it living and breathing. On 12 Dec 2009, at 22:46, Jay K wrote: > eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. > scrollertvbtclass is pretty close, though current adds "shadows". > Maybe we're ok in practise, but I still don't like it. > > (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging > feeling that Trestle reinvents far more than most other gui libraries.) > > - Jay > > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Date: Sun, 13 Dec 2009 03:41:25 +0000 > Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 > > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 13 19:30:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Dec 2009 13:30:18 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B242DA5.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> Message-ID: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > Jay: > > Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. > > Regards, > Randy > > >>> Jay K 12/12/2009 10:41 PM >>> > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 02:43:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 01:43:56 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: Randy's changes make the Windows GUI look more like Windows. My changes make mentor not crash starting up just by checking for NIL and taking a lock. I don't understand Trestle's locking and the comments explaining it were too long for me to understand, so I'm just guessing. Given how ugly and non-uniform X Windows GUIs tend to be, Trestle being a good example -- it has its own unique ugly look, changing is not a bad idea, but not done here. - Jay From: hosking at cs.purdue.edu Date: Sun, 13 Dec 2009 13:30:18 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 14 12:42:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Dec 2009 12:42:57 +0100 Subject: [M3devel] pickle bug..solved?.. not supposed to work? In-Reply-To: <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> References: , <4B243970.1E75.00D7.1@scires.com> <1D761D8E-6BA3-456B-8C90-4C222FA533D7@cs.purdue.edu> Message-ID: <20091214124257.35dc33zjnkws0ks0@mail.elegosoft.com> Quoting Tony Hosking : > Yes, v1 is there in case anyone has v1 pickles they want to decode. I'd also vote for making V2 pickles the default. We could rename Pickle to Pickle1 and Pickle2 to Pickle and document this as an semantically incompatible change. Or is there really much interest in reading old pickle versions? Olaf > On 13 Dec 2009, at 00:50, Jay K wrote: > >> I assume there is a need to keep the code around for compatibility? >> You know -- to read existing files? >> And to keep testing that? >> And write them at least so the tests can read them back? >> >> >> But maybe we should take a read-only attitude? >> >> >> And switch the quake netobj=netobj1 to netobj=netobj2? >> >> >> It's tough..if you convert-upon-write, and people are >> running old programs, you'll break their files. >> >> >> It's also tough, you know, I think this stuff is too automatic. >> I'm pretty sure we should change the Text internal representation, >> but I'm also pretty sure the persistance (disk) representation >> is automatically derived from the transient (memory) >> representation and changing the second breaks the first. >> >> >> You know, I suspect it is like those systems >> that do: >> >> >> struct foo a; >> fwrite(&a, sizeof(a)); >> >> >> but just with endian/wordsize conversions and >> hashes/typeid to do checks upon read, so it >> won't crash if you change things, but it also won't >> read back successfully. >> >> >> Maybe the v1 limitations are good as well, in that maybe >> it is faster, and sometimes the limitations don't matter??? >> >> >> - Jay >> >> >> Date: Sun, 13 Dec 2009 00:52:53 -0500 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] pickle bug..solved?.. not supposed to work? >> >> Jay: >> >> I've done a lot with Pickles and with NetObj. >> >> I switched to the v2 version a long time ago and never looked back. >> >> IMO, we should switch over to v2 exclusively and consider v1 >> obsolete. Perhaps some others should comment on this to see if >> they share my opinion. >> >> Regards, >> Randy >> >> >>> Jay K 12/13/2009 12:34 AM >>> >> >> https://projects.elego.de/cm3/ticket/1068 >> >> >> >> >> >> I've only spent a few minutes here. >> >> Trying to find the relative code and such. >> >> >> >> >> >> The code is here: >> >> >> >> >> >> C:\dev2\cm3.2\m3-comm\netobj\tests\perf\src >> >> >> >> I found it by looking near the top of the stack in >> >> the bug report -- NetObjTest.m3 -- and >> >> then dir /s/b NetObjTest.m3. >> >> >> >> or find . | grep NetObjTest.m3$ on Unix. >> >> >> >> >> >> It appears that Pickle v1 and v2 are both >> >> available in the same library. >> >> There is INTERFACE Pickle and INTERFACE Pickle2. >> >> >> >> >> >> It appears netobj can use either. >> >> >> >> If you look at the stack in the bug, there is a lot of "v1" stuff. >> >> >> >> >> >> We provide Quake functions: >> >> >> >> readonly proc netobjv1(intf, type) is >> ... >> >> end >> >> >> >> readonly proc Netobjv1(intf, type) is >> ... >> >> end >> >> >> >> readonly proc netobjv2(intf, type) is >> ... >> >> end >> >> >> >> readonly proc netobj(intf, type) is >> netobjv1(intf, type) >> end >> >> >> >> >> >> >> v1 pickles cannot cross endian/wordsize boundaries. >> >> >> >> >> >> I think the bug is not so much in the pickle code, nor in the netobj code, >> >> but in the test code, or the running of it. >> >> >> >> Tests involving v1 won't work crossing endian/wordsize boundaries. >> >> V1 tests probably should still run, and maybe detect the mismatch >> >> and just claim success? >> >> >> >> And then v2 should get better coverage? >> >> >> >> >> >> Any more bugs then? >> >> I was procrastinating on this because I've never done anything with pickles > > -- 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 From wagner at elegosoft.com Mon Dec 14 12:59:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Dec 2009 12:59:50 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> Quoting Jay K : > I keep trying to understand Trestle but I keep failing. > I tried to read the comments explaining how its locking > works and I got lost quickly. Actually the Trestle locking was `verified' after the implementation was finished with the Extended Statical Checker written at that time in Modula-3, too (but reimplemented since then in Java). See SRC report 159, for example here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 This is where all the locking level pragmas come from. > I suspect that compares well to other GUI libraries > in that they probably just don't do threading well. I always thought that using threads extensively to keep the application responding to user request was one of the strong areas of Testle. > Easy to understand though. > > The Trestle apps are all pretty ugly and oddly behaved. > Granted, I have no "real use" for them. I just exercise > them a bit as test cases. > > I did notice you made the scrollbars look "nice" on Windows. > > The close box is marked "C". > The grow box is marked "G". I grant that making it look better would probably increase the user acceptance. IMO there's no reason not to do that; but there hasn't been anybody interested in working on it yet. > Yuck. > > As I said though, the more I look into Trestle, the more I think > it is implementing a rather complete "windows system" and not > just a library of widgets, nor even widgets + resizing algorithms. > Nor even just widgets + resizing + event routing. > > Like, it seems to also manage clipping, knowing what needs > redrawing, etc. > > But I'm not sure. > > It adds up to a lot of code, is my concern. > > That is good and bad. Yes. But it's a huge project to integrate another GUI library into M3 and make it as useful as Trestle. 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 From jay.krell at cornell.edu Mon Dec 14 13:52:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 12:52:12 +0000 Subject: [M3devel] darwin user threads? Message-ID: It looks like make/get/set/swapcontext aren't viable on MacOSX 10.5. Better on 10.6? x86 getcontext seems to corrupt things such that a crash follows shortly. AMD64 just doesn't work. I happen to be experimenting again with see http://www.engelschall.com/pw/usenix/2000/pmt-html/ again to ease OpenBSD porting..and had some luck on Darwin, though had trouble getting the timer to trigger ever or more than once. $ cat 1.c && gcc -m32 1.c && file a.out && ./a.out ; gcc -m64 1.c && file a.out && ./a.out #include #include #include int main() { ucontext_t a; int b = getcontext(&a); printf("%d %d\n", b, errno); return 0; } a.out: Mach-O executable i386 0 0 Segmentation fault a.out: Mach-O 64-bit executable x86_64 -1 45 $ grep 45 /usr/include/sys/errno.h #define ENOTSUP 45 /* Operation not supported */ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 13:58:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 12:58:02 +0000 Subject: [M3devel] darwin user threads? In-Reply-To: References: Message-ID: oh, search the web for "Darwin getcontext": http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 14 Dec 2009 12:52:12 +0000 Subject: [M3devel] darwin user threads? It looks like make/get/set/swapcontext aren't viable on MacOSX 10.5. Better on 10.6? x86 getcontext seems to corrupt things such that a crash follows shortly. AMD64 just doesn't work. I happen to be experimenting again with see http://www.engelschall.com/pw/usenix/2000/pmt-html/ again to ease OpenBSD porting..and had some luck on Darwin, though had trouble getting the timer to trigger ever or more than once. $ cat 1.c && gcc -m32 1.c && file a.out && ./a.out ; gcc -m64 1.c && file a.out && ./a.out #include #include #include int main() { ucontext_t a; int b = getcontext(&a); printf("%d %d\n", b, errno); return 0; } a.out: Mach-O executable i386 0 0 Segmentation fault a.out: Mach-O 64-bit executable x86_64 -1 45 $ grep 45 /usr/include/sys/errno.h #define ENOTSUP 45 /* Operation not supported */ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 16:10:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 10:10:37 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> Do you mean mentor crashing on Windows? I would not like us to introduce new bugs to X11-based Trestle by merging Windows with X11 Trestle. On 13 Dec 2009, at 20:43, Jay K wrote: > Randy's changes make the Windows GUI look more like > Windows. My changes make mentor not crash starting > up just by checking for NIL and taking a lock. > I don't understand Trestle's locking and the comments > explaining it were too long for me to understand, > so I'm just guessing. > > Given how ugly and non-uniform X Windows GUIs tend to be, > Trestle being a good example -- it has its own > unique ugly look, changing is not a bad idea, > but not done here. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Sun, 13 Dec 2009 13:30:18 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 > > Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. > > > On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > > Jay: > > Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. > > Regards, > Randy > > >>> Jay K 12/12/2009 10:41 PM >>> > 2008-05-27 02:29 rcoleburn > > * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, > vbtkitresources/close.ppm, vbtkitresources/down.ppm, > vbtkitresources/grow.ppm, vbtkitresources/left.ppm, > vbtkitresources/m3makefile, vbtkitresources/right.ppm, > vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, > lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, > vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, > lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, > vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, > vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: > > Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. > > > Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? > Can the work be redone against the 2008 versions? And factor out the common parts? > > I guess I should go and diff these against the 3.6 or 4.1 versions? > And then apply those diffs to the Posix file to get the Win32 version? > (Or again, try to share what is the same?) > > > - Jay > > > Date: Sun, 13 Dec 2009 04:37:34 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 09/12/13 04:37:34 > > > > Modified files: > > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > > m3makefile > > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > > ScrollerVBTClass.m3 > > > > Log message: > > I forgot to mention: I'm really just guessing here. It seems to work. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 16:14:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 10:14:33 -0500 Subject: [M3devel] darwin user threads? In-Reply-To: References: Message-ID: <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> I knew about this issue at the time I implemented user threads and extensively tested it successfully on my OS X 10.5 laptop. It must have gotten broken when you reorganized everything. Can you put the _XOPEN_SOURCE define back in please! On 14 Dec 2009, at 07:58, Jay K wrote: > > oh, search the web for "Darwin getcontext": > > http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html > > Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 16:14:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 15:14:40 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242DA5.1E75.00D7.1@scires.com>, , <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, , <3C76A3D5-3B10-4504-BDBD-46A544B16750@cs.purdue.edu> Message-ID: Yes it was crashing on Windows. It wasn't really "Windows-specific", it was specifically in the code Randy added. The two files are largely the same and they are both portable. It's just a matter of what pictures get drawn using the same underlying Trestle graphics functions. That is, the code is portable either way, it's just a behaviorial/visual decision that is made. You know, you could perfectly well allow: mentor -gui-style=windows mentor -gui-style=trestle You know, this isn't low level code, it is "middle". - Jay From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:10:37 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Do you mean mentor crashing on Windows? I would not like us to introduce new bugs to X11-based Trestle by merging Windows with X11 Trestle. On 13 Dec 2009, at 20:43, Jay K wrote:Randy's changes make the Windows GUI look more like Windows. My changes make mentor not crash starting up just by checking for NIL and taking a lock. I don't understand Trestle's locking and the comments explaining it were too long for me to understand, so I'm just guessing. Given how ugly and non-uniform X Windows GUIs tend to be, Trestle being a good example -- it has its own unique ugly look, changing is not a bad idea, but not done here. - Jay From: hosking at cs.purdue.edu Date: Sun, 13 Dec 2009 13:30:18 -0500 To: rcoleburn at scires.com CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote:Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards,Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 16:17:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 15:17:20 +0000 Subject: [M3devel] darwin user threads? In-Reply-To: <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> References: , <9643A6EE-68B4-4F02-A312-5535BCD81332@cs.purdue.edu> Message-ID: I didn't break it. It is not broken. I was "unhappy" at the non portability I had setup for OpenBSD..was trying sigaltstack again..was testing on Mac.. - Jay Subject: Re: [M3devel] darwin user threads? From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:14:33 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I knew about this issue at the time I implemented user threads and extensively tested it successfully on my OS X 10.5 laptop. It must have gotten broken when you reorganized everything. Can you put the _XOPEN_SOURCE define back in please! On 14 Dec 2009, at 07:58, Jay K wrote: oh, search the web for "Darwin getcontext": http://lists.apple.com/archives/darwin-userlevel/2008/Apr/msg00014.html Fix for x86 is #define _XOPEN_SOURCE to get the struct to be the right size -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Dec 14 17:31:01 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 14 Dec 2009 08:31:01 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20091214134015.9044F2474001@birch.elegosoft.com>, , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu> Message-ID: <20091214163101.109F61A2078@async.async.caltech.edu> Alpha is little-endian because it's DEC and all DEC systems are little-endian. It's one of those religious wars, now long forgotten... DEC did win that war, after all, but much good it did them. Also regarding Trestle: there are several tech reports about it that explain the locking schemes in detail. Are there really other windowing systems out there that have similarly good support for multithreaded programs? (I've certainly never seen one...I think Trestle is very very cool.) Mika Jay K writes: >--_53b61834-1f8f-4857-9285-039cb0730d0c_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I assumed Alpha was little endian because it ran NT. >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > Linux and AIX?) > >Target.m3: > > (* big endian *) > > IF TextUtils.StartsWith(system=2C "PA") > > (* MIPS is definitely ambiguous! *) > OR TextUtils.StartsWith(system=2C "MIPS") > =20 > (* PPC is a little ambiguous? *) > OR TextUtils.StartsWith(system=2C "PPC") > > OR TextUtils.StartsWith(system=2C "SPARC") > OR TextUtils.StartsWith(system=2C "SOL") THEN > Little_endian :=3D FALSE=3B > END=3B > >Anyway it shouldn't be hard to track down. >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= >ng around...) > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= >s correct=2C and it /has/ no survived a fair number of combinations. I do c= >ross builds /almost/ without considering host and target. Er=2C except you = >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= >as started hitting me more often... it's just something where the compiler = >gets confused and does host math with target limitations=2C where it should= > do target math. > > - Jay > >From: hosking at cs.purdue.edu >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 >To: jay.krell at cornell.edu >CC: m3commit at elegosoft.com >Subject: Re: [M3commit] CVS Update: cm3 > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > code. I rewrote it=2C at least once. >Cross compiling works. >Native does not. >It must be the threshold variables in RTCollector. > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > earliest use of FP in the run-time linker. If they are broken you find ou= >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = >one point just fine on native Alpha 64-bit=2C so should not be too hard to = >fix. >I really thought I understood that code. > > - Jay > > >From: hosking at cs.purdue.edu >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 >To: jkrell at elego.de >CC: m3commit at elegosoft.com >Subject: Re: [M3commit] CVS Update: cm3 > >This suggests an m3cg backend compiler problem for floating point on SPARC6= >4. >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs >Changes by: jkrell at birch. 09/12/14 14:40:15 > >Modified files: > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > cm3/m3-libs/m3core/src/unix/: m3makefile=20 >Removed files: > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > >Log message: > updates so SPARC64_SOLARIS bootstrap can build > (possible tangent related to getting SPARC64_OPENBSD > to work -- problem apparently with the floating point > constants in RTCollector=2C such that Behind() is > always TRUE=2C even for the first allocation=2C so > access violate trying to garbage collect too > early=2C when self is still NULL) > > > = > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= >w=2C a lot of chips go either way these days (PowerPC little endian for NT = >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?)>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = >has been sitting around...)

The code I put in parse.c is definitely = >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = >fair number of combinations. I do cross builds /almost/ without considering= > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= >obably fix that pretty soon as it has started hitting me more often... it's= > just something where the compiler gets confused and does host math with ta= >rget limitations=2C where it should do target math.

 =3B- Jay>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> >
parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= >transform: none=3B white-space: normal=3B word-spacing: 0px=3B">=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= >te-space: normal=3B word-spacing: 0px=3B">
rd=3B">te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B">"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= >e-space: normal=3B word-spacing: 0px=3B">" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= >d-spacing: 0px=3B">apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= >ne=3B white-space: normal=3B word-spacing: 0px=3B">style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > 0px=3B">rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= >=2C at 10:43=2C Jay K wrote:
>

interchange-newline">
=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= >mpiling works.
Native does not.
It must be the threshold variables in= > RTCollector.

Yeah=2C I've= > been bitten by just that scenario in the past -- those are the earliest us= >e of FP in the run-time linker.  =3BIf they are broken you find out qui= >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > hard to fix.

e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= >ally thought I understood that code.

 =3B- Jay


=3D"ecxstopSpelling">From: =3B= >hosking at cs.purdue.edur>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To:verted-space"> =3Bjkrell at eleg= >o.de
CC: =3Bref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= >: Re: [M3commit] CVS Update: cm3

le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= >=3B word-spacing: 0px=3B">order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= >px=3B">
tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= >al=3B word-spacing: 0px=3B">"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > 0px=3B">eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= >ng: 0px=3B">: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">
Apple-style-span" style=3D"font-size: medium=3B">-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= >ackend compiler problem for floating point on SPARC64.
<= >/span>
= >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= >e:

CVSR= >OOT: pan>/usr/cvs
Changes by:ite-space: pre=3B"> jkrell at birch." style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= >iles:
> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 class=3D"ecxApple-converted-space"> =3B
xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= >rc/unix/: m3makefile =3B>
Removed files:
space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= >ignal.m3 =3B

Log= > message:
=3B"> updates so SPARC64_SOLARIS bootstrap can build
=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= >angent related to getting SPARC64_OPENBSD
-span" style=3D"white-space: pre=3B"> to work -- problem apparently = >with the floating point
ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= >s
span>always TRUE=2C even for the first allocation=2C so
cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= >rying to garbage collect too
=3D"white-space: pre=3B"> early=2C when self is still NULL)
>


ine">

>= > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- From jay.krell at cornell.edu Mon Dec 14 17:31:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:31:29 +0000 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). It still seemed to hang. (I realize you might not have meant that.) So what happens if none of our user threads have any work? Is that possible? Sure, I can make it so. Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). Will they actually wake up after that time? And we won't spin the CPU in the meantime? I guess I should test it out.. I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. But I wonder also..you have OpenBSD/x86 or sparc64? cd to that test bed, make, ./tcontext. It always seemed kind of jerky. I bet it'll seem "faster" with "real" timer. - Jay From: hosking at cs.purdue.edu Date: Mon, 14 Dec 2009 10:39:31 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Main thread should call Yield if you want that behavior, not sleep. On 14 Dec 2009, at 14:57, Jay Krell wrote:CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/12/14 14:57:30 Added files: cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: Makefile config.c context.c context.h m3makefile tcontext.c Log message: working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ - This should be moved to m3core/src/thread/POSIX - Notice how I switched from virtual timer to real timer, in the test case that mimics m3core/src/thread/POSIX. "This seems to work much better." In particular, if the main thread does while (1) sleep(0) to let things run, nothing runs. The virtual time doesn't run down at all. If I make it a busy wait "while (1) ;" then it does work. Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). This solution might be preferred? Though it is slower to create a thread here, due to extra gymnastics to establish the initial context. Also still some experiments to try. _setjmp vs. setjmp vs. sigsetjmp. Best is probably sigsetjmp(1). using the same signal in both parts -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 17:39:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:39:40 +0000 Subject: [M3devel] Trestle In-Reply-To: <20091214163101.109F61A2078@async.async.caltech.edu> References: <20091214134015.9044F2474001@birch.elegosoft.com>, , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu> , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: I'm pretty sure Win32 doesn't have great GUI threading. Each Window has affinity to the thread it is created on -- all events to it are delivered to that thread. I'm pretty sure Java doesn't have great GUI threading. I remember historically that the X client (Xlib) wasn't historically even thread safe. However the server must be, since it is interacting with multiple processes. I doubt Trestle an really overcome the limits of the underlying systems though. My wording was poor. I can't remove Trestle, of course. But providing an alternative is still not a terrible idea. All my "research" (highly non scientific) says Qt is the way. As to how/if it would fit into Modula-3, I have little idea..and not a lot of time/interest either. The results generally look and behave better imho. The platform support (esp. Windows) is better. I'm aware that there are /many/ options and I'm aware of the unclear licensing issues. Probably it is one of those things that is free for use by "open source", and we probably quality, but not free for commercial use. Really, though, nothing going on here. Not worth arguing about. (Maybe I'll "merge" the X/Win32 Scroller, so that it is one body of code with ifs, but I'd leave X looking as it does (ugly), just reducing overall code volume and probably increasing maintainability (they don't directly correspond, but often largely do). - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 14 Dec 2009 08:31:01 -0800 > From: mika at async.async.caltech.edu > > > Alpha is little-endian because it's DEC and all DEC systems are > little-endian. It's one of those religious wars, now long forgotten... > DEC did win that war, after all, but much good it did them. > > Also regarding Trestle: there are several tech reports about it that > explain the locking schemes in detail. Are there really other windowing > systems out there that have similarly good support for multithreaded > programs? (I've certainly never seen one...I think Trestle is very > very cool.) > > Mika > > Jay K writes: > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I assumed Alpha was little endian because it ran NT. > >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= > >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > > Linux and AIX?) > > > >Target.m3: > > > > (* big endian *) > > > > IF TextUtils.StartsWith(system=2C "PA") > > > > (* MIPS is definitely ambiguous! *) > > OR TextUtils.StartsWith(system=2C "MIPS") > > =20 > > (* PPC is a little ambiguous? *) > > OR TextUtils.StartsWith(system=2C "PPC") > > > > OR TextUtils.StartsWith(system=2C "SPARC") > > OR TextUtils.StartsWith(system=2C "SOL") THEN > > Little_endian :=3D FALSE=3B > > END=3B > > > >Anyway it shouldn't be hard to track down. > >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= > >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= > >ng around...) > > > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= > >s correct=2C and it /has/ no survived a fair number of combinations. I do c= > >ross builds /almost/ without considering host and target. Er=2C except you = > >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= > >as started hitting me more often... it's just something where the compiler = > >gets confused and does host math with target limitations=2C where it should= > > do target math. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 > >To: jay.krell at cornell.edu > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > > code. I rewrote it=2C at least once. > >Cross compiling works. > >Native does not. > >It must be the threshold variables in RTCollector. > > > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > > earliest use of FP in the run-time linker. If they are broken you find ou= > >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = > >one point just fine on native Alpha 64-bit=2C so should not be too hard to = > >fix. > >I really thought I understood that code. > > > > - Jay > > > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 > >To: jkrell at elego.de > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > >This suggests an m3cg backend compiler problem for floating point on SPARC6= > >4. > >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/12/14 14:40:15 > > > >Modified files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > > cm3/m3-libs/m3core/src/unix/: m3makefile=20 > >Removed files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > > > >Log message: > > updates so SPARC64_SOLARIS bootstrap can build > > (possible tangent related to getting SPARC64_OPENBSD > > to work -- problem apparently with the floating point > > constants in RTCollector=2C such that Behind() is > > always TRUE=2C even for the first allocation=2C so > > access violate trying to garbage collect too > > early=2C when self is still NULL) > > > > > > = > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= > >w=2C a lot of chips go either way these days (PowerPC little endian for NT = > >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?) >>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= > >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= > >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = > >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = > >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= > >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= > >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= > >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= > >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= > >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= > >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= > >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = > >has been sitting around...)

The code I put in parse.c is definitely = > >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = > >fair number of combinations. I do cross builds /almost/ without considering= > > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= > >obably fix that pretty soon as it has started hitting me more often... it's= > > just something where the compiler gets confused and does host math with ta= > >rget limitations=2C where it should do target math.

 =3B- Jay >>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= > >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> > > >
>parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= > >transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= > >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= > >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= > >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= > >te-space: normal=3B word-spacing: 0px=3B">
>rd=3B"> >te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= > >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= > >=2C at 10:43=2C Jay K wrote:
 >>

>interchange-newline">
>=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= > >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = > >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= > >mpiling works.
Native does not.
It must be the threshold variables in= > > RTCollector.

Yeah=2C I've= > > been bitten by just that scenario in the past -- those are the earliest us= > >e of FP in the run-time linker.  =3BIf they are broken you find out qui= > >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= > >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > > hard to fix.

>e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= > >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = > >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= > >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= > >ally thought I understood that code.

 =3B- Jay


>=3D"ecxstopSpelling">From: =3B= > >hosking at cs.purdue.edu >r>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To: >verted-space"> =3Bjkrell at eleg= > >o.de
CC: =3B >ref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= > >: Re: [M3commit] CVS Update: cm3

>le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= > >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= > >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= > >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= > >=3B word-spacing: 0px=3B"> >order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= > >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= > >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= > >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= > >px=3B">
>tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= > >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= > >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= > >al=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = > >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= > >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= > >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= > >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B"> >-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= > >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= > >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= > >ng: 0px=3B"> >: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= > >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= > >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= > >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= > >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= > >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= > >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B">
>Apple-style-span" style=3D"font-size: medium=3B"> >-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= > >ackend compiler problem for floating point on SPARC64.
<= > >/span>
= > >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= > >e:

CVSR= > >OOT: >pan>/usr/cvs
Changes by: >ite-space: pre=3B"> jkrell at birch. >" style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= > >iles:
>> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 > class=3D"ecxApple-converted-space"> =3B
>xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= > >rc/unix/: m3makefile =3B >>
Removed files:
>space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= > >ignal.m3 =3B

Log= > > message:
>=3B"> updates so SPARC64_SOLARIS bootstrap can build
>=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= > >angent related to getting SPARC64_OPENBSD
>-span" style=3D"white-space: pre=3B"> to work -- problem apparently = > >with the floating point
>ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= > >s
>span>always TRUE=2C even for the first allocation=2C so
>cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= > >rying to garbage collect too
>=3D"white-space: pre=3B"> early=2C when self is still NULL)
>>


>ine">

> >= > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 17:43:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 16:43:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091214163101.109F61A2078@async.async.caltech.edu> References: <20091214134015.9044F2474001@birch.elegosoft.com>, , , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , , , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu>, , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: >> all DEC systems are little-endian Ok, educate me. VAX little endian? MIPS-based DecStations running Ultrix little endian? (again, MIPS ran NT, but MIPS is "well known" to be "either" there's often "mips" and "mipsle", "le"="little endian") Alpha/VMS little endian? Alpha/Tru64 little endian? IA64/VMS little endian? (IA64/HPUX little endian?) (Alpha/IA64/MIPS/PPC NT yes little all endian) - Jay > To: jay.krell at cornell.edu > Date: Mon, 14 Dec 2009 08:31:01 -0800 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Alpha is little-endian because it's DEC and all DEC systems are > little-endian. It's one of those religious wars, now long forgotten... > DEC did win that war, after all, but much good it did them. > > Also regarding Trestle: there are several tech reports about it that > explain the locking schemes in detail. Are there really other windowing > systems out there that have similarly good support for multithreaded > programs? (I've certainly never seen one...I think Trestle is very > very cool.) > > Mika > > Jay K writes: > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I assumed Alpha was little endian because it ran NT. > >Then again=2C I know=2C a lot of chips go either way these days (PowerPC li= > >ttle endian for NT and presumably XBox360=2C big endian for Mac and I think= > > Linux and AIX?) > > > >Target.m3: > > > > (* big endian *) > > > > IF TextUtils.StartsWith(system=2C "PA") > > > > (* MIPS is definitely ambiguous! *) > > OR TextUtils.StartsWith(system=2C "MIPS") > > =20 > > (* PPC is a little ambiguous? *) > > OR TextUtils.StartsWith(system=2C "PPC") > > > > OR TextUtils.StartsWith(system=2C "SPARC") > > OR TextUtils.StartsWith(system=2C "SOL") THEN > > Little_endian :=3D FALSE=3B > > END=3B > > > >Anyway it shouldn't be hard to track down. > >I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC64_{LINUX=2CDA= > >RWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware has been sitti= > >ng around...) > > > >The code I put in parse.c is definitely wierd=2C but I really thought it wa= > >s correct=2C and it /has/ no survived a fair number of combinations. I do c= > >ross builds /almost/ without considering host and target. Er=2C except you = > >can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it h= > >as started hitting me more often... it's just something where the compiler = > >gets confused and does host math with target limitations=2C where it should= > > do target math. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:46:25 -0500 > >To: jay.krell at cornell.edu > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > >On 14 Dec 2009=2C at 10:43=2C Jay K wrote:I know I know. I know exactly the= > > code. I rewrote it=2C at least once. > >Cross compiling works. > >Native does not. > >It must be the threshold variables in RTCollector. > > > >Yeah=2C I've been bitten by just that scenario in the past -- those are the= > > earliest use of FP in the run-time linker. If they are broken you find ou= > >t quickly. Can you take a look at the gcc m3cg code for FP? It worked at = > >one point just fine on native Alpha 64-bit=2C so should not be too hard to = > >fix. > >I really thought I understood that code. > > > > - Jay > > > > > >From: hosking at cs.purdue.edu > >Date: Mon=2C 14 Dec 2009 10:38:06 -0500 > >To: jkrell at elego.de > >CC: m3commit at elegosoft.com > >Subject: Re: [M3commit] CVS Update: cm3 > > > >This suggests an m3cg backend compiler problem for floating point on SPARC6= > >4. > >On 14 Dec 2009=2C at 14:40=2C Jay Krell wrote:CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/12/14 14:40:15 > > > >Modified files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3=20 > > cm3/m3-libs/m3core/src/unix/: m3makefile=20 > >Removed files: > > cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3=20 > > > >Log message: > > updates so SPARC64_SOLARIS bootstrap can build > > (possible tangent related to getting SPARC64_OPENBSD > > to work -- problem apparently with the floating point > > constants in RTCollector=2C such that Behind() is > > always TRUE=2C even for the first allocation=2C so > > access violate trying to garbage collect too > > early=2C when self is still NULL) > > > > > > = > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I assumed Alpha was little endian because it ran NT.
Then again=2C I kno= > >w=2C a lot of chips go either way these days (PowerPC little endian for NT = > >and presumably XBox360=2C big endian for Mac and I think Linux and AIX?) >>
Target.m3:

 =3B =3B =3B (* big endian *)

&nb= > >sp=3B =3B =3B IF TextUtils.StartsWith(system=2C "PA")

 = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B (* MIPS is definitely ambiguous! *)
 =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B OR TextUtils.= > >StartsWith(system=2C "MIPS")
 =3B =3B
 =3B =3B = > >=3B =3B =3B =3B =3B =3B =3B =3B =3B (* PPC = > >is a little ambiguous? *)
 =3B =3B =3B =3B =3B = > >=3B =3B =3B =3B =3B =3B OR TextUtils.StartsWith(system= > >=2C "PPC")

 =3B =3B =3B =3B =3B =3B =3B&= > >nbsp=3B =3B =3B =3B OR TextUtils.StartsWith(system=2C "SPARC")<= > >br> =3B =3B =3B =3B =3B =3B =3B =3B =3B= > > =3B =3B OR TextUtils.StartsWith(system=2C "SOL") THEN
 =3B&= > >nbsp=3B =3B =3B =3B =3B =3B Little_endian :=3D FALSE=3B= > >
 =3B =3B =3B END=3B

Anyway it shouldn't be hard to t= > >rack down.
I'll probably divert to SPARC64_SOLARIS first=2C or maybe PPC= > >64_{LINUX=2CDARWIN} (iMac G5 arrived recently=2C though PPC64_AIX hardware = > >has been sitting around...)

The code I put in parse.c is definitely = > >wierd=2C but I really thought it was correct=2C and it /has/ no survived a = > >fair number of combinations. I do cross builds /almost/ without considering= > > host and target. Er=2C except you can't cross from 64bit to 32bit..I'll pr= > >obably fix that pretty soon as it has started hitting me more often... it's= > > just something where the compiler gets confused and does host math with ta= > >rget limitations=2C where it should do target math.

 =3B- Jay >>
From: hosking at cs.purdue.edu
Date: Mon=2C 14= > > Dec 2009 10:46:25 -0500
To: jay.krell at cornell.edu
CC: m3commit at elego= > >soft.com
Subject: Re: [M3commit] CVS Update: cm3

> > > >
>parate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B= > > letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-= > >transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0= > >=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: nor= > >mal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: norma= > >l=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whi= > >te-space: normal=3B word-spacing: 0px=3B">
>rd=3B"> >te=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C= > > 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p= > >x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B">On 14 Dec 2009= > >=2C at 10:43=2C Jay K wrote:
 >>

>interchange-newline">
>=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: mediu= > >m=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l= > >etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr= > >ansform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I know = > >I know. I know exactly the code. I rewrote it=2C at least once.
Cross co= > >mpiling works.
Native does not.
It must be the threshold variables in= > > RTCollector.

Yeah=2C I've= > > been bitten by just that scenario in the past -- those are the earliest us= > >e of FP in the run-time linker.  =3BIf they are broken you find out qui= > >ckly.  =3BCan you take a look at the gcc m3cg code for FP?  =3BIt w= > >orked at one point just fine on native Alpha 64-bit=2C so should not be too= > > hard to fix.

>e=3D"border-collapse: separate=3B font-family: Helvetica=3B font-size: medi= > >um=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B = > >letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-t= > >ransform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family: Verdana=3B">I re= > >ally thought I understood that code.

 =3B- Jay


>=3D"ecxstopSpelling">From: =3B= > >hosking at cs.purdue.edu >r>Date: Mon=2C 14 Dec 2009 10:38:06 -0500
To: >verted-space"> =3Bjkrell at eleg= > >o.de
CC: =3B >ref=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com
Subject= > >: Re: [M3commit] CVS Update: cm3

>le-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B f= > >ont-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-vari= > >ant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height= > >: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: normal= > >=3B word-spacing: 0px=3B"> >order-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helveti= > >ca=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font= > >-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-in= > >dent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0= > >px=3B">
>tyle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B= > > font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-va= > >riant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heig= > >ht: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norm= > >al=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B"> >eparate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: = > >12px=3B font-style: normal=3B font-variant: normal=3B font-weight: normal= > >=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B te= > >xt-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >ass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color:= > > rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-styl= > >e: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing:= > > normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B"> >-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: He= > >lvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B= > > font-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B te= > >xt-indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spaci= > >ng: 0px=3B"> >: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-siz= > >e: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: norma= > >l=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B t= > >ext-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >lass=3D"ecxecxApple-style-span" style=3D"border-collapse: separate=3B color= > >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= > >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= > >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= > >=3B white-space: normal=3B word-spacing: 0px=3B">
>Apple-style-span" style=3D"font-size: medium=3B"> >-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">This suggests an m3cg b= > >ackend compiler problem for floating point on SPARC64.
<= > >/span>
= > >

On 14 Dec 2009=2C at 14:40=2C Jay Krell wrot= > >e:

CVSR= > >OOT: >pan>/usr/cvs
Changes by: >ite-space: pre=3B"> jkrell at birch. >" style=3D"white-space: pre=3B"> 09/12/14 14:40:15

Modified f= > >iles:
>> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 > class=3D"ecxApple-converted-space"> =3B
>xApple-tab-span" style=3D"white-space: pre=3B"> cm3/m3-libs/m3core/s= > >rc/unix/: m3makefile =3B >>
Removed files:
>space: pre=3B"> cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTS= > >ignal.m3 =3B

Log= > > message:
>=3B"> updates so SPARC64_SOLARIS bootstrap can build
>=3D"ecxecxApple-tab-span" style=3D"white-space: pre=3B"> (possible t= > >angent related to getting SPARC64_OPENBSD
>-span" style=3D"white-space: pre=3B"> to work -- problem apparently = > >with the floating point
>ite-space: pre=3B"> constants in RTCollector=2C such that Behind() i= > >s
>span>always TRUE=2C even for the first allocation=2C so
>cxecxApple-tab-span" style=3D"white-space: pre=3B"> access violate t= > >rying to garbage collect too
>=3D"white-space: pre=3B"> early=2C when self is still NULL)
>>


>ine">

> >= > > > >--_53b61834-1f8f-4857-9285-039cb0730d0c_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 17:55:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 11:55:14 -0500 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: <951B9075-1A76-4A45-8A13-2E8B5A2AF277@cs.purdue.edu> Scheduler.Yield()? We allow programmers to disable preemptive thread scheduling with user-level threads and simply get yields at appropriate thread primitives (LOCK, Wait, etc.). If you have a loop like that with a non-preemptive user-level thread scheduler the only way to guarantee switching is to call Yield. On 14 Dec 2009, at 11:31, Jay K wrote: > Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). > It still seemed to hang. > (I realize you might not have meant that.) > > > So what happens if none of our user threads have any work? Is that possible? > Sure, I can make it so. > Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). > Will they actually wake up after that time? > And we won't spin the CPU in the meantime? > I guess I should test it out.. > > > I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. > But I wonder also..you have OpenBSD/x86 or sparc64? > cd to that test bed, make, ./tcontext. > It always seemed kind of jerky. > I bet it'll seem "faster" with "real" timer. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 10:39:31 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Main thread should call Yield if you want that behavior, not sleep. > > On 14 Dec 2009, at 14:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/14 14:57:30 > > Added files: > cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: > Makefile > config.c > context.c > context.h > m3makefile > tcontext.c > > Log message: > working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ > - This should be moved to m3core/src/thread/POSIX > - Notice how I switched from virtual timer to real timer, > in the test case that mimics m3core/src/thread/POSIX. > "This seems to work much better." > In particular, if the main thread does while (1) sleep(0) > to let things run, nothing runs. The virtual time doesn't > run down at all. If I make it a busy wait "while (1) ;" then > it does work. > > Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). > This solution might be preferred? Though it is slower to create a thread here, due to > extra gymnastics to establish the initial context. > > Also still some experiments to try. > _setjmp vs. setjmp vs. sigsetjmp. > Best is probably sigsetjmp(1). > using the same signal in both parts > > From hosking at cs.purdue.edu Mon Dec 14 17:56:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 11:56:30 -0500 Subject: [M3devel] real timer vs. virtual timer in user threads? In-Reply-To: References: <20091214135730.A8B302474001@birch.elegosoft.com>, <641797AB-42E3-4797-99A0-A9123953DFF5@cs.purdue.edu> Message-ID: <4AF3AD39-F883-49AD-BB49-6C26F11A69C0@cs.purdue.edu> On 14 Dec 2009, at 11:31, Jay K wrote: > Ok, so I tried sched_yield in my C testbed (m3core/src/unix/Common/context/sigaltstack). > It still seemed to hang. > (I realize you might not have meant that.) > > > So what happens if none of our user threads have any work? Is that possible? > Sure, I can make it so. > Just create a bunch of threads that call the Modula-3 equivalent of sleep(big number). > Will they actually wake up after that time? Good point. Depends on what the OS timer implementation will do. We may have threads blocked on IO too, but they will wake in the select call. > And we won't spin the CPU in the meantime? > I guess I should test it out.. > > > I can see that "virtual" does seem maybe better than "real", if the virtual one is guaranteed to progress. > But I wonder also..you have OpenBSD/x86 or sparc64? > cd to that test bed, make, ./tcontext. > It always seemed kind of jerky. > I bet it'll seem "faster" with "real" timer. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 10:39:31 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Main thread should call Yield if you want that behavior, not sleep. > > On 14 Dec 2009, at 14:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/14 14:57:30 > > Added files: > cm3/m3-libs/m3core/src/unix/Common/context/sigaltstack/: > Makefile > config.c > context.c > context.h > m3makefile > tcontext.c > > Log message: > working version of http://www.engelschall.com/pw/usenix/2000/pmt-html/ > - This should be moved to m3core/src/thread/POSIX > - Notice how I switched from virtual timer to real timer, > in the test case that mimics m3core/src/thread/POSIX. > "This seems to work much better." > In particular, if the main thread does while (1) sleep(0) > to let things run, nothing runs. The virtual time doesn't > run down at all. If I make it a busy wait "while (1) ;" then > it does work. > > Note that Apple seems very down on supplying get/make/set/swapcontext (read the mailing lists). > This solution might be preferred? Though it is slower to create a thread here, due to > extra gymnastics to establish the initial context. > > Also still some experiments to try. > _setjmp vs. setjmp vs. sigsetjmp. > Best is probably sigsetjmp(1). > using the same signal in both parts > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:04:18 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:04:18 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> Message-ID: <4B262845.1E75.00D7.1@scires.com> Jay, you should only see the "C" and "G" on POSIX platforms, not Windows. We could also change the behavior on POSIX to match Windows if everyone desires, or perhaps we could provide a switch capability to choose. --Randy >>> Jay K 12/13/2009 12:47 AM >>> I keep trying to understand Trestle but I keep failing. I tried to read the comments explaining how its locking works and I got lost quickly. I suspect that compares well to other GUI libraries in that they probably just don't do threading well. Easy to understand though. The Trestle apps are all pretty ugly and oddly behaved. Granted, I have no "real use" for them. I just exercise them a bit as test cases. I did notice you made the scrollbars look "nice" on Windows. The close box is marked "C". The grow box is marked "G". Yuck. As I said though, the more I look into Trestle, the more I think it is implementing a rather complete "windows system" and not just a library of widgets, nor even widgets + resizing algorithms. Nor even just widgets + resizing + event routing. Like, it seems to also manage clipping, knowing what needs redrawing, etc. But I'm not sure. It adds up to a lot of code, is my concern. That is good and bad. - Jay Date: Sun, 13 Dec 2009 00:12:21 -0500 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] FW: Win32/ScrollerVBTClass.m3 Jay: You would get opposition from anyone who likes Trestle and FormsVBT. Really, the concepts, simplicity, and extensibility of Trestle/FormsVBT are very good and probably ahead of their time in terms of the then current state of commercial practice. Ditching Trestle would not bode well for any of the work I've done. I have a lot of cm3 code that runs on both Unix X-Windows and on Windows without any application source modification. Indeed, having a GUI that worked on both types of platforms was one of the main selling points/features of the work we did in Modula-3 back in the late 90's. Also, to follow up on my prior response, one of the reasons it took 11 years for me to incorporate the Win32 customizations had to do with licensing and also with standing up the repository after the demise of the commercial cm3 venture. Not much had been done to these sources over the 11 years. Mainly, I think most of the changes had to do with stuff that came out of PM3 and some bug fixes. So, I had to get back into this code and do a real merge/integration effort taking care not to break anything. Regards, Randy >>> Jay K 12/12/2009 10:46 PM >>> eh, actually zchassis 3.6 matches current posix zchassis except for whitespace. scrollertvbtclass is pretty close, though current adds "shadows". Maybe we're ok in practise, but I still don't like it. (Really I'd love to ditch Trestle in favor of Qt or such, but I have this nagging feeling that Trestle reinvents far more than most other gui libraries.) - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Sun, 13 Dec 2009 03:41:25 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:13:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:13:37 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> Message-ID: <4B262A74.1E75.00D7.1@scires.com> No, I think you misinterpret what I was trying to say. I did not make any changes affecting the way the GUI looks on POSIX. The changes were only on the Windows side to make the GUI look more like Windows. These changes were based on work that Critical Mass, Inc. performed under contract to my company. We have given these changes back to the M3 community by the work I did to integrate them into the then-current source tree. I have subsequently fixed a few bugs in the code over the past couple years. Regards, Randy >>> Tony Hosking 12/13/2009 1:30 PM >>> Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. On 13 Dec 2009, at 00:02, Randy Coleburn wrote: Jay: Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. Regards, Randy >>> Jay K 12/12/2009 10:41 PM >>> 2008-05-27 02:29 rcoleburn * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, vbtkitresources/close.ppm, vbtkitresources/down.ppm, vbtkitresources/grow.ppm, vbtkitresources/left.ppm, vbtkitresources/m3makefile, vbtkitresources/right.ppm, vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? Can the work be redone against the 2008 versions? And factor out the common parts? I guess I should go and diff these against the 3.6 or 4.1 versions? And then apply those diffs to the Posix file to get the Win32 version? (Or again, try to share what is the same?) - Jay > Date: Sun, 13 Dec 2009 04:37:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/12/13 04:37:34 > > Modified files: > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 > m3makefile > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 > ScrollerVBTClass.m3 > > Log message: > I forgot to mention: I'm really just guessing here. It seems to work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 18:12:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 12:12:33 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B262A74.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com> <4B242DA5.1E75.00D7.1@scires.com> <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu> <4B262A74.1E75.00D7.1@scires.com> Message-ID: So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. 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 14 Dec 2009, at 12:13, Randy Coleburn wrote: > No, I think you misinterpret what I was trying to say. > > I did not make any changes affecting the way the GUI looks on POSIX. > > The changes were only on the Windows side to make the GUI look more like Windows. These changes were based on work that Critical Mass, Inc. performed under contract to my company. We have given these changes back to the M3 community by the work I did to integrate them into the then-current source tree. > > I have subsequently fixed a few bugs in the code over the past couple years. > > Regards, > Randy > > >>> Tony Hosking 12/13/2009 1:30 PM >>> > Is that what these changes do? Make POSIX GUI like Windows. Let's please not do that gratuitously. > > > On 13 Dec 2009, at 00:02, Randy Coleburn wrote: > >> Jay: >> >> Back in 2008 when I made these changes I did go to the current source tree and factor all this work into the then current tree. It was not a file replace situation, but rather very careful work trying to merge the changes back into the current tree. The POSIX implementation did not change, because the modifications were intended for Windows only. I think it would be wrong to try and make the GUI on Unix look like Windows. >> >> Regards, >> Randy >> >> >>> Jay K 12/12/2009 10:41 PM >>> >> 2008-05-27 02:29 rcoleburn >> >> * m3-ui/vbtkit/src/: lego/m3makefile, vbtkitresources/ScrollBg, >> vbtkitresources/close.ppm, vbtkitresources/down.ppm, >> vbtkitresources/grow.ppm, vbtkitresources/left.ppm, >> vbtkitresources/m3makefile, vbtkitresources/right.ppm, >> vbtkitresources/up.ppm, lego/POSIX/ScrollerVBTClass.m3, >> lego/POSIX/ZChassisVBT.m3, lego/POSIX/m3makefile, >> vbtkitutils/m3makefile, lego/WIN32/ScrollerVBTClass.m3, >> lego/WIN32/ZChassisVBT.m3, lego/WIN32/m3makefile, >> vbtkitutils/POSIX/VBTKitEnv.i3, vbtkitutils/POSIX/m3makefile, >> vbtkitutils/WIN32/VBTKitEnv.i3, vbtkitutils/WIN32/m3makefile: >> >> Incorporate changes made to vbtkit by Critical Mass circa September 1997 that make the GUI appearance more like that of Windows. The m3makefiles have been adjusted so that these changes affect only Windows (WIN32) platforms. These changes were part of work sponsored by Randy Coleburn at Scientific Research Corporation (SRC). The main files affected are VBTKitEnv.i3, ScrollerVBTClass.m3, and ZChassisVBT.m3, plus some new resource files have been added for WIN32 only. >> >> >> Randy, are files from 1997 really correct to incorporate into the tree 11 years later? Or maybe they are rather out of date? >> Can the work be redone against the 2008 versions? And factor out the common parts? >> >> I guess I should go and diff these against the 3.6 or 4.1 versions? >> And then apply those diffs to the Posix file to get the Win32 version? >> (Or again, try to share what is the same?) >> >> >> - Jay >> >> > Date: Sun, 13 Dec 2009 04:37:34 +0000 >> > To: m3commit at elegosoft.com >> > From: jkrell at elego.de >> > Subject: [M3commit] CVS Update: cm3 >> > >> > CVSROOT: /usr/cvs >> > Changes by: jkrell at birch. 09/12/13 04:37:34 >> > >> > Modified files: >> > cm3/m3-ui/vbtkit/src/lego/: Tag: release_branch_cm3_5_8 >> > m3makefile >> > cm3/m3-ui/vbtkit/src/lego/WIN32/: Tag: release_branch_cm3_5_8 >> > ScrollerVBTClass.m3 >> > >> > Log message: >> > I forgot to mention: I'm really just guessing here. It seems to work. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 14 18:19:17 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 14 Dec 2009 12:19:17 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> Message-ID: <4B262BC8.1E75.00D7.1@scires.com> >>> Olaf Wagner 12/14/2009 6:59 AM >>> >> >> I did notice you made the scrollbars look "nice" on Windows. >> >> The close box is marked "C". >> The grow box is marked "G". >I grant that making it look better would probably increase the user >acceptance. IMO there's no reason not to do that; but there hasn't been >anybody interested in working on it yet. Olaf, it would be easy to factor some of these appearance changes from the Windows-specific code back into the POSIX-specific code. I could do it, but we should first make sure everyone wants this type of behavior. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 18:36:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Dec 2009 17:36:56 +0000 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, <4B262A74.1E75.00D7.1@scires.com>, Message-ID: > So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. I did not. How many times I need to say I didn't touch the Posix code? We have posix/scroller and win32/scroller. win32/scroller is a copy/edit of posix/scroller. You can hypothetically compile either on either. It is all portable. To alter the appearance, they are different. In the code that made win32/scroller there was some crashing. I fixed that. To the extent that they are the same, I suggest the two files be merged into one, with "if"s. You know, like, you have approximately three choices in these things. Separate files, #if, and if. But with Modula-3, #if goes away. But you still have "if", depending on what the code looks like. If the branches are wildly divergent, for some definition of "wild", then separate files are appropriate. If the divergence is small, for some definition of "small", then "if" is preferable. Depending on the degree, "if" can be confusing. Too man ifs, hard to read the code fast and see what actually runs. Separate files obviously can lead to redundancy. In fact my first fix was to always use the Posix code. Since it worked and didn't crash. But then I fixed the crash instead. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 14 19:06:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 13:06:57 -0500 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: References: <20091213033734.E108E2474002@birch.elegosoft.com>, , <4B242DA5.1E75.00D7.1@scires.com>, <2336D72E-F0C3-4971-B138-566354F3E4FC@cs.purdue.edu>, <4B262A74.1E75.00D7.1@scires.com>, Message-ID: <98166A57-C9AF-40E0-9F91-49AC4AE18ABB@cs.purdue.edu> OK, cool. :-) On 14 Dec 2009, at 12:36, Jay K wrote: > > So what did Jay recently do? It sounded like he was migrating your code from the Windows implementation to the POSIX implementation. > > I did not. How many times I need to say I didn't touch the Posix code? > > > We have posix/scroller and win32/scroller. > win32/scroller is a copy/edit of posix/scroller. > You can hypothetically compile either on either. > It is all portable. > To alter the appearance, they are different. > In the code that made win32/scroller there was some crashing. > I fixed that. > > > To the extent that they are the same, I suggest the > two files be merged into one, with "if"s. > You know, like, you have approximately three choices > in these things. > Separate files, #if, and if. > But with Modula-3, #if goes away. > But you still have "if", depending on what the code looks like. > > > If the branches are wildly divergent, for some definition of "wild", > then separate files are appropriate. > If the divergence is small, for some definition of "small", > then "if" is preferable. > > > Depending on the degree, "if" can be confusing. > Too man ifs, hard to read the code fast and see what > actually runs. > Separate files obviously can lead to redundancy. > > > > In fact my first fix was to always use the Posix code. > Since it worked and didn't crash. > But then I fixed the crash instead. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Dec 14 19:12:56 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 14 Dec 2009 10:12:56 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20091214134015.9044F2474001@birch.elegosoft.com>, , , <5A4A51CF-0063-4E4F-93C7-9B950B55C562@cs.purdue.edu>, , , , <45D55E81-8BE6-40DB-BD52-0BAC1027F29D@cs.purdue.edu>, , <20091214163101.109F61A2078@async.async.caltech.edu> Message-ID: <20091214181256.2AEDB1A2078@async.async.caltech.edu> Jay K writes: >--_dcd80a02-fc6b-42d8-93c7-943543066a21_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > >> all DEC systems are little-endian > >Ok=2C educate me. > > VAX little endian?=20 definitely > MIPS-based DecStations running Ultrix little endian?=20 > (again=2C MIPS ran NT=2C but MIPS is "well known" to be "either" there's= yes, definitely > often "mips" and "mipsle"=2C "le"=3D"little endian")=20 > Alpha/VMS little endian?=20 yes > Alpha/Tru64 little endian? =20 yes > IA64/VMS little endian? =20 no idea but I would suspect so > (IA64/HPUX little endian?) no idea > (Alpha/IA64/MIPS/PPC NT yes little all endian)=20 This was one of the things IBM and DEC used to send people out to flame each other over. How each is obviously superior to the other, "wrong-endian" system. This was a while ago.... Mika From peter.mckinna at gmail.com Tue Dec 15 01:27:27 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 15 Dec 2009 11:27:27 +1100 Subject: [M3devel] pickle bug..solved?.. not supposed to work? Message-ID: <3d9e5afc0912141627u2d9d2389k16544f95b815c36a@mail.gmail.com> I also vote for making V2 the default. I think the stubgen code has a hard coded setting making the protocol V1 somewhere. That would have to be fixed as well. Also there is a bunch of imports in various modules of the form Import Pickle2 as Pickle that would have to be changed. Also I have a couple of fixes for the ConvertPacking module for v2 that I should put in to do with 64-32 conversion. I think Blair MacIntyre did a lot of the extension for V2 and you see comments in the code where he has made various changes. I wonder what the etiquette is of removing those comments and leaving a reference to his work in header at the top? Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:01:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:01:55 +0000 Subject: [M3devel] RegisterFinalCleanup and locking? Message-ID: I think RegisterFinalCleanup should be augmented or changed so that caller can use it without holding a lock, thereby avoiding holding two locks (RegisterFinalCleanup uses heap lock) and worrying about the order/deadlock. Some sort of reserve/commit, reserve/cancel system. Like: cleanup := ReserveFinalCleanup(); (* can fail with exception*) cleanup.object := mutex; cleanup.function := CleanMutex; ... CommitFinalCleanup(cleanup); (* cannot fail *) or CancelFinalCleanup(cleanup); (* cannot fail *) I think it might not be at all difficult. Or: cleanup := ReserveFinalCleanup(); (* can fail with exception *) .. CommitFinalCleanup(cleanup, mutex, CleanMutex); or CancelFinalCleanup(cleanup); or: cleanup := ReserveFinalCleanup(mutex, CleanMutex); (* can fail with exception *) and then optional CancelFinalCleanup(cleanup); but not sure the last one is viable. Maybe: UnsafeCollectNow(mutex); ? Hm. Do we have that already? DISPOSE on traced references in unsafe code? And it does or does not handle the registered cleanup? I'll check. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:06:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:06:45 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? Message-ID: Is it possible to initialize mutexes and condition variables right away? Instead of having the delayed initialization? Mutex initialization is pretty fast on Windows, no syscall. Having it be delayed like it is maybe isn't worthwhile. As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? I know there is the idiom NEW(T).init() but that is up to callers to adhere to. Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 04:17:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 03:17:27 +0000 Subject: [M3devel] win32 conditionvariables Message-ID: I didn't realize it, but the Java code, now the Modula-3 code is the same as: http://www.cs.wustl.edu/~schmidt/win32-cv-1.html "3.3. The Generation Count Solution" including the downsides he lists -- some unfairness. Now that I notice the similarity, I'll compare against this one as well. And maybe "rewrite" in Modula-3 instead of the current C. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 04:49:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 22:49:48 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: Message-ID: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) On 14 Dec 2009, at 22:06, Jay K wrote: > Is it possible to initialize mutexes and condition variables right away? > Instead of having the delayed initialization? > > > Mutex initialization is pretty fast on Windows, no syscall. > Having it be delayed like it is maybe isn't worthwhile. > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > - Jay > From jay.krell at cornell.edu Tue Dec 15 05:04:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:04:17 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: Is it possible to do on Win32? Win32 critical sections are cheap and already probably work roughly "that way". Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. Our (new) win32 condition variables are not cheap, but similar in cost to Java. (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 22:49:48 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > Is it possible to initialize mutexes and condition variables right away? > > Instead of having the delayed initialization? > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 05:18:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:18:22 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu>, Message-ID: ps: maybe we can hope for the folks under us implementing pthread_mutex and criticalsection to do a very good job? We have much more context?? Inlining?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 15 Dec 2009 04:04:17 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? Is it possible to do on Win32? Win32 critical sections are cheap and already probably work roughly "that way". Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. Our (new) win32 condition variables are not cheap, but similar in cost to Java. (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 22:49:48 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004) > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > Is it possible to initialize mutexes and condition variables right away? > > Instead of having the delayed initialization? > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > I know there is the idiom NEW(T).init() but that is up to callers to adhere to. > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 05:26:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 23:26:43 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: We need an compiler intrinsic CAS to avoid calls. More incentive to get the gcc-based backend working on Windows? I'll bet most modern Java implementations destroy thread libraries on performance. In the uncontended case they have no atomic operations, and the code is all inline. I'm not sure what Java implementation you are looking at... (Hotspot's sucks BTW). On 14 Dec 2009, at 23:04, Jay K wrote: > Is it possible to do on Win32? > Win32 critical sections are cheap and already probably work roughly "that way". > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > - Jay > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > From: hosking at cs.purdue.edu > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > Is it possible to initialize mutexes and condition variables right away? > > > Instead of having the delayed initialization? > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > - Jay > > > > > From hosking at cs.purdue.edu Tue Dec 15 05:39:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Dec 2009 23:39:08 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> Message-ID: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> So, the basic scenario is as follows. Briefly... We should ditch signals as a mechanism for stopping threads. The compiler should inject a "safe-point" at each procedure call and backward branch. At safe-points, the thread polls a thread-local to see if the run-time system needs it to step out-of-line for some reason. At calls to <*EXTERNAL*> procedures we set a thread-local to say the thread is stepping outside Modula-3 code, with corresponding synchronized test on return in case the run-time needs it to pay attention. Now, when a MUTEX is first acquired, we simply CAS in a bit in the MUTEX along with the acquiring thread's ID. That thread can then release and acquire as often as it likes, no further CAS, no pthread_mutex_lock. Acquirers must always CAS to see if the bit is set. If it is then the lock is reserved for some other thread. We must revoke the reservation by handshake (as described above) with the reserving thread. We then inflate a real pthread_mutex_lock along with any queues needed for the MUTEX/CV. The handshake mechanism can also be used for stopping threads for GC, etc. The point is that uncontended locks should cost almost nothing. On 14 Dec 2009, at 23:04, Jay K wrote: > Is it possible to do on Win32? > Win32 critical sections are cheap and already probably work roughly "that way". > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > - Jay > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > From: hosking at cs.purdue.edu > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > Is it possible to initialize mutexes and condition variables right away? > > > Instead of having the delayed initialization? > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > - Jay > > > > > From jay.krell at cornell.edu Tue Dec 15 05:47:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 04:47:33 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: References: , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> , Message-ID: Yes HotSpot. I guess I should look at others and JITed code. C# too. So, question..Java probably has to perf because people probably abuse it. They have to counteract deficiencies elsewhere. Similar for us? Granted, I removed the win32 thread cache. And there was a criticalsection cache in the past. No function call or interlock in uncontended is impressive..you could do that based on the Hotspot code..but is it worth..the inlining bloat and "dependencies" (changes requiring recompiling clients). The gcc backend does work on Windows. In a fashion, a fairly practical fashion. With "mingw" you can just go and configure && make and you get a gcc that doesn't use cygwin. I'm more interested in improving the fast integrated one, or maybe llvm support. Something that writes out .obj files and doesn't require so many processes. Debugging is a mixed story too. Integrated backend outputs only function symbols and line number. Nothing for locals or types. gcc output I believe debuggable only with gdb, at least the cygwin gcc. We can get CAS et. al. without resorting to gcc. As a function call or probably inline. I think that locks in a dependency on newer processors and/or operating systems though. If the integrated backend is missing CAS and that is holding you up, speak up. The integrated backend is just incredibly faster than the gcc backend, both to build and run. - Jay > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 23:26:43 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We need an compiler intrinsic CAS to avoid calls. More incentive to get the gcc-based backend working on Windows? > I'll bet most modern Java implementations destroy thread libraries on performance. In the uncontended case they have no atomic operations, and the code is all inline. I'm not sure what Java implementation you are looking at... (Hotspot's sucks BTW). > > On 14 Dec 2009, at 23:04, Jay K wrote: > > > Is it possible to do on Win32? > > Win32 critical sections are cheap and already probably work roughly "that way". > > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > > > - Jay > > > > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > > From: hosking at cs.purdue.edu > > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > > CC: m3devel at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > > > Is it possible to initialize mutexes and condition variables right away? > > > > Instead of having the delayed initialization? > > > > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 15 06:13:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Dec 2009 05:13:22 +0000 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> References: , , <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu>, , <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> Message-ID: > That thread can then release and acquire as often as it likes, no further CAS, no > pthread_mutex_lock. Acquirers must always CAS to see if the bit is set How does the thread know it doesn't need to CAS? With a non-atomic check? > polls a thread-local Expensive currently. Can be improved a la gcc __thread, Win32 __declspec(thread), but with limits. __declspec(thread) doesn't work pre-Vista with .dlls loaded "after" the .exe. You can detect that though and switch between two paths. The "reserved" parameter to DllMain tells you if you are loaded in CreateProcess or LoadLibrary, and therefore if __declspec(thread) works pre-Vista or if you need to use TlsAlloc/TlsGetValue. You wouldn't want to inline that though, so "poll a thread local" is a function call. If there are multiple backward branches in a function, you can optimize by remembering the address of the thread local in a "normal" local, certainly. You can also possibly..I haven't thought this through, but I think for each function you can generate two entry points. Call them "internal" and "external". "internal" takes an extra pointer, the pointer to the thread locals. "external" gets the thread locals in an expensive fashion (above) and calls "internal". If a function doesn't actually need the thread locals, the two are aliased to each other. Within a module (a single .m3 file), you always call internal, or maybe within a library/dll, or maybe within Modula-3 entirely. But callbacks or direct calls from C go to external. Though callbacks can do better. Even C calls could do better, if you can break the C/Modula-3 ABI. I'm not sure this overall scheme works out, but I think it does. This is similar to how in some systems exported functions are duplicated. The exported version retrieves the base pointer for the .dll's data and then calls the non-exported one. NT/PPC, NT/IA64, I think Mac/CFM/PPC and others work this way. I believe it helps achieve position independence, all static data is accessed via a register that is maintained for all entry and/or exit from a .dll. > calls to <*EXTERNAL*> procedures Arguably we can do whatever needed in our .c code. You know, since <*external*> is now largely but not completely implemented by us. I realize there's still e.g. X/Windows, OpenGL, Win32. Only "libc" is wrapped aggressively right now, and others are large. And maybe that is all that should be, e.g. OpenGL and Xlib are very portable and so maybe cloning their headers is too? - Jay > From: hosking at cs.purdue.edu > Date: Mon, 14 Dec 2009 23:39:08 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > So, the basic scenario is as follows. Briefly... We should ditch signals as a mechanism for stopping threads. The compiler should inject a "safe-point" at each procedure call and backward branch. At safe-points, the thread polls a thread-local to see if the run-time system needs it to step out-of-line for some reason. At calls to <*EXTERNAL*> procedures we set a thread-local to say the thread is stepping outside Modula-3 code, with corresponding synchronized test on return in case the run-time needs it to pay attention. Now, when a MUTEX is first acquired, we simply CAS in a bit in the MUTEX along with the acquiring thread's ID. That thread can then release and acquire as often as it likes, no further CAS, no pthread_mutex_lock. Acquirers must always CAS to see if the bit is set. If it is then the lock is reserved for some other thread. We must revoke the reservation by handshake (as described above) with the reserving thread. We then inflate a real pthread_mutex_lock along with any queues needed for the MUTEX/CV. The handshake mechanism can also be used for stopping threads for GC, etc. > > The point is that uncontended locks should cost almost nothing. > > On 14 Dec 2009, at 23:04, Jay K wrote: > > > Is it possible to do on Win32? > > Win32 critical sections are cheap and already probably work roughly "that way". > > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap. > > > > Our (new) win32 condition variables are not cheap, but similar in cost to Java. > > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.) > > > > - Jay > > > > > > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable? > > > From: hosking at cs.purdue.edu > > > Date: Mon, 14 Dec 2009 22:49:48 -0500 > > > CC: m3devel at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to: > > > > > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258?268. Montre ?al, Canada (Jun 1998) > > > > > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot > > > > > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79?90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html > > > > > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479?495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf > > > > > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130?141. Seattle, Washington (Nov 2002) > > > > > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223?237. Denver, Colorado (Nov 1999) > > > > > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559?583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4) > > > > > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263?272. Portland, Oregon (Oct 2006) > > > > > > On 14 Dec 2009, at 22:06, Jay K wrote: > > > > > > > Is it possible to initialize mutexes and condition variables right away? > > > > Instead of having the delayed initialization? > > > > > > > > > > > > Mutex initialization is pretty fast on Windows, no syscall. > > > > Having it be delayed like it is maybe isn't worthwhile. > > > > > > > > > > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ? > > > > > > > > > > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to. > > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess. > > > > > > > > > > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init? > > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete. > > > > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 15 11:42:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Dec 2009 11:42:47 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B262FC7.1E75.00D7.1@scires.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> Message-ID: <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > Can you supply me with SRC Report 159 ? > > The link you give doesn't seem to know how to serve up the report. Strange. I had no problem to download it there. I'll CC m3devel in case anybody else cannot get it. Olaf > I would like to better understand the locking level pragmas. > > Regards, > Randy > >>>> Olaf Wagner 12/14/2009 6:59 AM >>> > Quoting Jay K : > >> I keep trying to understand Trestle but I keep failing. >> I tried to read the comments explaining how its locking >> works and I got lost quickly. > > Actually the Trestle locking was `verified' after the implementation > was finished with the Extended Statical Checker written at that time > in Modula-3, too (but reimplemented since then in Java). See > SRC report 159, for example here: > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 > > This is where all the locking level pragmas come from. > >> I suspect that compares well to other GUI libraries >> in that they probably just don't do threading well. > > I always thought that using threads extensively to keep the > application > responding to user request was one of the strong areas of Testle. > >> Easy to understand though. >> >> The Trestle apps are all pretty ugly and oddly behaved. >> Granted, I have no "real use" for them. I just exercise >> them a bit as test cases. >> >> I did notice you made the scrollbars look "nice" on Windows. >> >> The close box is marked "C". >> The grow box is marked "G". > > I grant that making it look better would probably increase the user > acceptance. IMO there's no reason not to do that; but there hasn't > been > anybody interested in working on it yet. > >> Yuck. >> >> As I said though, the more I look into Trestle, the more I think >> it is implementing a rather complete "windows system" and not >> just a library of widgets, nor even widgets + resizing algorithms. >> Nor even just widgets + resizing + event routing. >> >> Like, it seems to also manage clipping, knowing what needs >> redrawing, etc. >> >> But I'm not sure. >> >> It adds up to a lot of code, is my concern. >> >> That is good and bad. > > Yes. But it's a huge project to integrate another GUI library into M3 > and make it as useful as Trestle. > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: SRC-report-159.pdf Type: application/pdf Size: 197231 bytes Desc: not available URL: From hendrik at topoi.pooq.com Tue Dec 15 15:08:46 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Dec 2009 09:08:46 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> Message-ID: <20091215140846.GA12996@topoi.pooq.com> On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: > So, the basic scenario is as follows. Briefly... We should ditch > signals as a mechanism for stopping threads. The compiler should > inject a "safe-point" at each procedure call and backward branch. At > safe-points, the thread polls a thread-local to see if the run-time > system needs it to step out-of-line for some reason. ... ... > > The point is that uncontended locks should cost almost nothing. Nothing? All those safe-points cost time, don't they, even when no locks are being used at all? Is this analogous to charging everyone for the overhead involved in recursion, even when no recursion is being used? -- hendrik From mika at async.async.caltech.edu Tue Dec 15 16:02:14 2009 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 15 Dec 2009 07:02:14 -0800 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215140846.GA12996@topoi.pooq.com> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> Message-ID: <20091215150214.D4E8D1A207A@async.async.caltech.edu> What's the main problem you guys are trying to solve? In my experience the biggest performance loss in moving from PM3 user threads to CM3 pthreads has been with programs that lock a lot but are actually not using the thread-safety for anything. Those programs would be improved greatly by a scheme such as the one Tony describes, where a mutex is "passed" between the threads, with "real locking" only when it has to be passed from one locker to another, not when a single locker locks and re-locks the mutex. But I don't see how that implies a need to change the thread-stopping mechanism.... it's something else, I take it? Mika hendrik at topoi.pooq.com writes: >On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >> So, the basic scenario is as follows. Briefly... We should ditch >> signals as a mechanism for stopping threads. The compiler should >> inject a "safe-point" at each procedure call and backward branch. At >> safe-points, the thread polls a thread-local to see if the run-time >> system needs it to step out-of-line for some reason. > >... >... >> >> The point is that uncontended locks should cost almost nothing. > >Nothing? All those safe-points cost time, don't they, even when no >locks are being used at all? > >Is this analogous to charging everyone for the overhead involved in >recursion, even when no recursion is being used? > >-- hendrik From hosking at cs.purdue.edu Tue Dec 15 16:18:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 10:18:17 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215140846.GA12996@topoi.pooq.com> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> Message-ID: Yes, good point. It really is a question of how much does the safe-point check cost. Perhaps for a "systems" language like Modula-3 it is important that we not tax code that doesn't use threads or locks. But in today's world code like that is less common, no? And Modula-3 positively encourages them. On the other hand, Modula-3 demands programmers explicitly declare their locks (unlike Java which says any object can be a lock or CV), so perhaps retaining the referential transparency of explicit locks (you don't pay unless you use them) is more in the Modula-3 "systems" programming way of thinking. There are other ways to do the safe-points. One could "poison" (access-protect) a page that the thread simply reads a location from at the safe-points, whereupon it will trap. But in some experiments we have done with Java, it is more important that the thread simply ack, rather than having actually to take a trap and come to a screeching halt in a signal handler. And, since most threads are usually blocked or executing some external system call, you don't even have to wait for the ack. On 15 Dec 2009, at 09:08, hendrik at topoi.pooq.com wrote: > On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >> So, the basic scenario is as follows. Briefly... We should ditch >> signals as a mechanism for stopping threads. The compiler should >> inject a "safe-point" at each procedure call and backward branch. At >> safe-points, the thread polls a thread-local to see if the run-time >> system needs it to step out-of-line for some reason. > > ... > ... >> >> The point is that uncontended locks should cost almost nothing. > > Nothing? All those safe-points cost time, don't they, even when no > locks are being used at all? > > Is this analogous to charging everyone for the overhead involved in > recursion, even when no recursion is being used? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 15 16:24:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 10:24:48 -0500 Subject: [M3devel] up-front initialization of mutex/conditionvariable? In-Reply-To: <20091215150214.D4E8D1A207A@async.async.caltech.edu> References: <7E31AD65-09D6-4A9C-96A8-6266BADDAE88@cs.purdue.edu> <78E8C63F-6512-4CF6-8B98-83A74E5C96C4@cs.purdue.edu> <20091215140846.GA12996@topoi.pooq.com> <20091215150214.D4E8D1A207A@async.async.caltech.edu> Message-ID: On 15 Dec 2009, at 10:02, Mika Nystrom wrote: > What's the main problem you guys are trying to solve? > > In my experience the biggest performance loss in moving from PM3 user > threads to CM3 pthreads has been with programs that lock a lot but are > actually not using the thread-safety for anything. Exactly. In "uniprocessor" user-threading, lock is simply INC(inCritical)/DEC(inCritical), which controls whether threads can switch or not. > Those programs would be improved greatly by a scheme such as the one > Tony describes, where a mutex is "passed" between the threads, with > "real locking" only when it has to be passed from one locker to another, > not when a single locker locks and re-locks the mutex. > > But I don't see how that implies a need to change the thread-stopping > mechanism.... it's something else, I take it? We could use a CAS on every acquire/release, implementing the Thin Locks technique mentioned in one of the papers I cited. I wanted to go one step more, to avoid the CAS (which has overhead beyond a simple load/store) by allowing a lock to be reserved to one thread the first time it is acquired. That thread gets to acquire/release without CAS. When another thread comes along and wants the lock it needs a mechanism to revoke the reservation. That's why we need the handshake mechanism. I could use the current signal-based approach, but that has the nasty effect of stopping the target thread in its tracks. Better that it simply ack the revocation and then keep running. > Mika > > hendrik at topoi.pooq.com writes: >> On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote: >>> So, the basic scenario is as follows. Briefly... We should ditch >>> signals as a mechanism for stopping threads. The compiler should >>> inject a "safe-point" at each procedure call and backward branch. At >>> safe-points, the thread polls a thread-local to see if the run-time >>> system needs it to step out-of-line for some reason. >> >> ... >> ... >>> >>> The point is that uncontended locks should cost almost nothing. >> >> Nothing? All those safe-points cost time, don't they, even when no >> locks are being used at all? >> >> Is this analogous to charging everyone for the overhead involved in >> recursion, even when no recursion is being used? >> >> -- hendrik From rodney_bates at lcwb.coop Tue Dec 15 22:23:50 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 15 Dec 2009 15:23:50 -0600 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> Message-ID: <4B27FE66.5010600@lcwb.coop> Olaf Wagner wrote: > Quoting Randy Coleburn : > >> Olaf: >> >> Can you supply me with SRC Report 159 ? >> >> The link you give doesn't seem to know how to serve up the report. I got some kind of permission failure when trying to get it via http: http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-159.ps.gz I manually edited the 'http' to 'ftp' and got it without trouble. I could also use ftp to see a listing of the parent directory, with all the SRC reports. > > Strange. I had no problem to download it there. > I'll CC m3devel in case anybody else cannot get it. > > Olaf > >> I would like to better understand the locking level pragmas. >> >> Regards, >> Randy >> >>>>> Olaf Wagner 12/14/2009 6:59 AM >>> >> Quoting Jay K : >> >>> I keep trying to understand Trestle but I keep failing. >>> I tried to read the comments explaining how its locking >>> works and I got lost quickly. >> >> Actually the Trestle locking was `verified' after the implementation >> was finished with the Extended Statical Checker written at that time >> in Modula-3, too (but reimplemented since then in Java). See >> SRC report 159, for example here: >> >> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9943 >> >> This is where all the locking level pragmas come from. >> >>> I suspect that compares well to other GUI libraries >>> in that they probably just don't do threading well. >> >> I always thought that using threads extensively to keep the >> application >> responding to user request was one of the strong areas of Testle. >> >>> Easy to understand though. >>> >>> The Trestle apps are all pretty ugly and oddly behaved. >>> Granted, I have no "real use" for them. I just exercise >>> them a bit as test cases. >>> >>> I did notice you made the scrollbars look "nice" on Windows. >>> >>> The close box is marked "C". >>> The grow box is marked "G". >> >> I grant that making it look better would probably increase the user >> acceptance. IMO there's no reason not to do that; but there hasn't >> been >> anybody interested in working on it yet. >> >>> Yuck. >>> >>> As I said though, the more I look into Trestle, the more I think >>> it is implementing a rather complete "windows system" and not >>> just a library of widgets, nor even widgets + resizing algorithms. >>> Nor even just widgets + resizing + event routing. >>> >>> Like, it seems to also manage clipping, knowing what needs >>> redrawing, etc. >>> >>> But I'm not sure. >>> >>> It adds up to a lot of code, is my concern. >>> >>> That is good and bad. >> >> Yes. But it's a huge project to integrate another GUI library into M3 >> and make it as useful as Trestle. >> >> Olaf From peter.mckinna at gmail.com Wed Dec 16 02:13:30 2009 From: peter.mckinna at gmail.com (Peter McKinna) Date: Wed, 16 Dec 2009 12:13:30 +1100 Subject: [M3devel] Hard real time Message-ID: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Hi, Is there any way to use the realtime options of pthreads, to set the scheduler and the mutex protocols for priority inherit etc, all that good stuff in an M3 program? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 02:18:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Dec 2009 20:18:53 -0500 Subject: [M3devel] Hard real time In-Reply-To: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Message-ID: <785B08D1-2A2E-4202-8D67-132C6D0E21A7@cs.purdue.edu> It would be possible if we supported APIs for that. On 15 Dec 2009, at 20:13, Peter McKinna wrote: > Hi, > > Is there any way to use the realtime options of pthreads, to set the scheduler and the mutex protocols for priority inherit etc, all that good stuff in an M3 program? > > Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 16 10:35:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 10:35:35 +0100 Subject: [M3devel] FW: Win32/ScrollerVBTClass.m3 In-Reply-To: <4B27FE66.5010600@lcwb.coop> References: <20091213033734.E108E2474002@birch.elegosoft.com>, , , , <4B242FF0.1E75.00D7.1@scires.com> <20091214125950.dxfcbjt36swc04cs@mail.elegosoft.com> <4B262FC7.1E75.00D7.1@scires.com> <20091215114247.sja5qcg6osowsgk4@mail.elegosoft.com> <4B27FE66.5010600@lcwb.coop> Message-ID: <20091216103535.ufbvdqddb0gwgc08@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Olaf Wagner wrote: >> Quoting Randy Coleburn : >> >>> Olaf: >>> >>> Can you supply me with SRC Report 159 ? >>> >>> The link you give doesn't seem to know how to serve up the report. > I got some kind of permission failure when trying to get it via http: > > http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-159.ps.gz > > I manually edited the 'http' to 'ftp' and got it without trouble. I could > also use ftp to see a listing of the parent directory, with all the SRC > reports. So gatekeeper is still online :-) I wonder if I should ask Greg Nelson if we could get the M3 code for ESC... but it's probably not going to be(come) open source, as it has been ported to Java since and may well be commercially used. It would be great if we had such a tool for CM3 though. 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 From wagner at elegosoft.com Wed Dec 16 10:39:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 10:39:06 +0100 Subject: [M3devel] Hard real time In-Reply-To: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com> Message-ID: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Quoting Peter McKinna : > Hi, > > Is there any way to use the realtime options of pthreads, to set the > scheduler and the mutex protocols for priority inherit etc, all that good > stuff in an M3 program? I don't know of such an interface, but it would be great if we had it. Is this stuff pthread standard, or more or less system dependent? 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 From jay.krell at cornell.edu Wed Dec 16 11:35:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 10:35:42 +0000 Subject: [M3devel] Hard real time In-Reply-To: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com>, <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Message-ID: search the web for: "setthreadpriority" "opengroup sched.h" http://www.opengroup.org/onlinepubs/007908799/xsh/sched.h.html http://msdn.microsoft.com/en-us/library/ms686277(VS.85).aspx etc. Would be good to abstract out something that can be done over pthreads and Win32 and possibly user threads. As I understand, "hard real time" is rare. You know, when page faults occur cannot be unpredictable and still be hard real time, right? "rough scheduling parameters", sure, but not "hard real time". You could also ignore Win32 and user threads and drop down into C and party on pthread_self(). That is, the key is coming up with portable interfaces and interface "policing". - Jay > Date: Wed, 16 Dec 2009 10:39:06 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hard real time > > Quoting Peter McKinna : > > > Hi, > > > > Is there any way to use the realtime options of pthreads, to set the > > scheduler and the mutex protocols for priority inherit etc, all that good > > stuff in an M3 program? > > I don't know of such an interface, but it would be great if we had > it. Is this stuff pthread standard, or more or less system dependent? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 11:39:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 10:39:34 +0000 Subject: [M3devel] Hard real time In-Reply-To: <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> References: <3d9e5afc0912151713p44307dbdn9b464483cf5b465a@mail.gmail.com>, <20091216103906.xz0ftjb28wc0g4so@mail.elegosoft.com> Message-ID: (We should port to QNX and VxWorks?) :) - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] Hard real time Date: Wed, 16 Dec 2009 10:35:42 +0000 search the web for: "setthreadpriority" "opengroup sched.h" http://www.opengroup.org/onlinepubs/007908799/xsh/sched.h.html http://msdn.microsoft.com/en-us/library/ms686277(VS.85).aspx etc. Would be good to abstract out something that can be done over pthreads and Win32 and possibly user threads. As I understand, "hard real time" is rare. You know, when page faults occur cannot be unpredictable and still be hard real time, right? "rough scheduling parameters", sure, but not "hard real time". You could also ignore Win32 and user threads and drop down into C and party on pthread_self(). That is, the key is coming up with portable interfaces and interface "policing". - Jay > Date: Wed, 16 Dec 2009 10:39:06 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hard real time > > Quoting Peter McKinna : > > > Hi, > > > > Is there any way to use the realtime options of pthreads, to set the > > scheduler and the mutex protocols for priority inherit etc, all that good > > stuff in an M3 program? > > I don't know of such an interface, but it would be great if we had > it. Is this stuff pthread standard, or more or less system dependent? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 13:37:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 12:37:38 +0000 Subject: [M3devel] providing "bootstrap" archives Message-ID: jay at xlin2:/dev2/cm3/scripts/python$ ls -l *gz -rw-r--r-- 1 jay jay 5002815 2009-12-16 04:15 cm3-boot-AMD64_FREEBSD-1.tar.gz -rw-r--r-- 1 jay jay 5004281 2009-12-16 04:30 cm3-boot-AMD64_OPENBSD-1.tar.gz -rw-r--r-- 1 jay jay 5225719 2009-12-16 03:45 cm3-boot-I386_DARWIN-1.tar.gz -rw-r--r-- 1 jay jay 4471845 2009-12-16 03:59 cm3-boot-I386_OPENBSD-1.tar.gz -rw-r--r-- 1 jay jay 5356193 2009-12-16 03:29 cm3-boot-PPC_DARWIN-1.tar.gz -rw-r--r-- 1 jay jay 5506665 2009-12-16 03:29 cm3-boot-PPC_LINUX-1.tar.gz -rw-r--r-- 1 jay jay 4871443 2009-12-16 03:05 cm3-boot-SPARC32_LINUX-1.tar.gz jay at xlin2:/dev2/cm3/scripts/python$ cat 1.sh for a in PPC_LINUX PPC_DARWIN I386_DARWIN I386_OPENBSD AMD64_FREEBSD \ AMD64_OPENBSD AMD64_LINUX AMD64_DARWIN SOLsun SOLgnu \ SPARC64_OPENBSD SPARC32_LINUX SPARC64_SOLARIS MIPS64_OPENBSD; do ./boot1.py $a done Possibly we should be running that in Hudson or something, on one or more machines? I believe there's one problem running it on 64 bit hosts. I'll fix that soon. These archives, copied to the target machine that contains cc/make/ld, possibly with a little bit of Makefile editing, can build cm3. And then from there you can build everything else. A bunch of cm3cg result too that maybe should be distributed somehow/somewhere. Probably "-1" should be changed to a real version/date. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Dec 16 13:57:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Dec 2009 13:57:20 +0100 Subject: [M3devel] providing "bootstrap" archives In-Reply-To: References: Message-ID: <20091216135720.a5b46rhbzq8o400c@mail.elegosoft.com> Quoting Jay K : > > jay at xlin2:/dev2/cm3/scripts/python$ ls -l *gz > -rw-r--r-- 1 jay jay 5002815 2009-12-16 04:15 cm3-boot-AMD64_FREEBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5004281 2009-12-16 04:30 cm3-boot-AMD64_OPENBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5225719 2009-12-16 03:45 cm3-boot-I386_DARWIN-1.tar.gz > -rw-r--r-- 1 jay jay 4471845 2009-12-16 03:59 cm3-boot-I386_OPENBSD-1.tar.gz > -rw-r--r-- 1 jay jay 5356193 2009-12-16 03:29 cm3-boot-PPC_DARWIN-1.tar.gz > -rw-r--r-- 1 jay jay 5506665 2009-12-16 03:29 cm3-boot-PPC_LINUX-1.tar.gz > -rw-r--r-- 1 jay jay 4871443 2009-12-16 03:05 cm3-boot-SPARC32_LINUX-1.tar.gz > > > jay at xlin2:/dev2/cm3/scripts/python$ cat 1.sh > for a in PPC_LINUX PPC_DARWIN I386_DARWIN I386_OPENBSD AMD64_FREEBSD \ > AMD64_OPENBSD AMD64_LINUX AMD64_DARWIN SOLsun SOLgnu \ > SPARC64_OPENBSD SPARC32_LINUX SPARC64_SOLARIS MIPS64_OPENBSD; do > ./boot1.py $a > done > > Possibly we should be running that in Hudson or something, on one or > more machines? Great! We should definitely add that to the Hudson jobs. I'm far behind there and hope to be able to do something during the Christmas break. It would be great if we could finish the release though and use the Hudson jobs for the trunk. There are not enough resources currently to do both, at least not on my or Elego's systems. Olaf > I believe there's one problem running it on 64 bit hosts. > > I'll fix that soon. > > These archives, copied to the target machine that contains > cc/make/ld, possibly > > with a little bit of Makefile editing, can build cm3. > > And then from there you can build everything else. > > > > > > A bunch of cm3cg result too that maybe should be distributed > somehow/somewhere. > > > > > > Probably "-1" should be changed to a real version/date. > > > > - Jay > -- 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 From jay.krell at cornell.edu Wed Dec 16 14:05:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 13:05:38 +0000 Subject: [M3devel] email hiccup Message-ID: Mail to me will see bounces but it does get through. I'm working on it. (see -- it gets forwarded to two places, one that I read, and one that is bouncing..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 16:36:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 15:36:24 +0000 Subject: [M3devel] pthread/Interix Message-ID: [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 16:40:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 15:40:04 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: References: Message-ID: (verified that empty records are of zero size; in C++ that's a not always possible optimization, they often have a filler byte, in order to generate unique addresses in places.) From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Wed, 16 Dec 2009 15:36:24 +0000 Subject: [M3devel] pthread/Interix [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 17:40:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 11:40:56 -0500 Subject: [M3devel] pthread/Interix In-Reply-To: References: Message-ID: <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote: > [again, expect a bounce, but the mail does get through] > > > Tony, for Interix, suspend/resume thread can be achieved writing to a file. > Getting a suspended thread's registers can be gotten reading from a file. > (I believe the same thing works on Solaris.) > It appears to be intended for debuggers. > I can see that it works well. > I doubt that a thread's context is on a signal handler's stack. > I propose: > > > ActState = { Starting, Started, Stopping, Stopped }; > REVEAL Activation = UNTRACED BRANDED REF RECORD > frame: ADDRESS := NIL; (* exception handling support *) > handle: pthread_t := NIL; (* LL = activeMu; thread handle *) > statusFile: int := -1; (* for Interix *) > controlFile: int := -1; (* for Interix *) > (* C code knows the structure above this point *) > ... > END; > > > ThreadPThread.h: > > > typedef struct _Activation_t { > void* frame; > void* pthread; > int statusFile; /* for Interix */ > int controlFile; /* for Interix */ > } Activation_t; > > > and then whereever we pass act.handle off to C code, pass act instead. > > > frame is kept first so that it is offset 0 in case that gives codegen efficiencies > on the often used push/popframe. > The other three are moved up to the top to reduce maintainence of ThreadPThread.h. > > > I assume "branding" doesn't introduce data in the record. > I'd have to check the codegen to verify frame is at offset 0. > > > #ifdef code will open the files. > Modula-3 code can check if the files are >= 0 and close them, > or it can be a call out to #ifdefed C. > > > An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. > (as VAR for initialization). > That is less fragile and less extensible. > I'm fine with that approach too. > > > As well though, I was wondering, maybe we should have: > > > common/InterixThreadState.i3 > T = RECORD END; (* zero size? *) > > > interix/InterixThreadState.i3 > T = RECORD statusFile, controlFile := -1; END; > > > and then put InterixThreadState.T in Activation. > That way saving the other platforms from spending the space. > Just two integers, not much, but in principle.. > (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, > on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) > > > I could also open/close the files for every suspend/resume/processStopped, > though that seems too lame. > > > Another idea, that I don't really like, is to never optimize and > ignore the registers and just use the stack. > I rarely optimize, but depending on that seems bad. > > > Your "safe points" proposal would also make this work, though > I'd rather not wait for that. > > > ? > > Ok to add the two integers all the time? > Ok to either depend on the record layout in C, or to always pass the integers around? > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 17:49:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 16:49:52 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> Message-ID: Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. There is only single parameter signal handlers. Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. That is what is particularly unfortunate. I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 11:40:56 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote: [again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 16 18:08:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 12:08:09 -0500 Subject: [M3devel] pthread/Interix In-Reply-To: References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> Message-ID: <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> On 16 Dec 2009, at 11:49, Jay K wrote: > Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. Interesting, this is exactly the way Mach does signals (which is why we use the Mach suspend/resume primitives for Darwin/OSX). If that is how they work, then can't you use the suspend/resume primitives directly? > There is only single parameter signal handlers. > > Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. > That is what is particularly unfortunate. > > I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. > > An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. > > (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) > > - Jay > > > Subject: Re: pthread/Interix > From: hosking at cs.purdue.edu > Date: Wed, 16 Dec 2009 11:40:56 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I really dislike this... just for a broken platform... > > Is there really no way to know that the context on is not on the stack somewhere? > > On 16 Dec 2009, at 10:36, Jay K wrote: > > [again, expect a bounce, but the mail does get through] > > > Tony, for Interix, suspend/resume thread can be achieved writing to a file. > Getting a suspended thread's registers can be gotten reading from a file. > (I believe the same thing works on Solaris.) > It appears to be intended for debuggers. > I can see that it works well. > I doubt that a thread's context is on a signal handler's stack. > I propose: > > > ActState = { Starting, Started, Stopping, Stopped }; > REVEAL Activation = UNTRACED BRANDED REF RECORD > frame: ADDRESS := NIL; (* exception handling support *) > handle: pthread_t := NIL; (* LL = activeMu; thread handle *) > statusFile: int := -1; (* for Interix *) > controlFile: int := -1; (* for Interix *) > (* C code knows the structure above this point *) > ... > END; > > > ThreadPThread.h: > > > typedef struct _Activation_t { > void* frame; > void* pthread; > int statusFile; /* for Interix */ > int controlFile; /* for Interix */ > } Activation_t; > > > and then whereever we pass act.handle off to C code, pass act instead. > > > frame is kept first so that it is offset 0 in case that gives codegen efficiencies > on the often used push/popframe. > The other three are moved up to the top to reduce maintainence of ThreadPThread.h. > > > I assume "branding" doesn't introduce data in the record. > I'd have to check the codegen to verify frame is at offset 0. > > > #ifdef code will open the files. > Modula-3 code can check if the files are >= 0 and close them, > or it can be a call out to #ifdefed C. > > > An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. > (as VAR for initialization). > That is less fragile and less extensible. > I'm fine with that approach too. > > > As well though, I was wondering, maybe we should have: > > > common/InterixThreadState.i3 > T = RECORD END; (* zero size? *) > > > interix/InterixThreadState.i3 > T = RECORD statusFile, controlFile := -1; END; > > > and then put InterixThreadState.T in Activation. > That way saving the other platforms from spending the space. > Just two integers, not much, but in principle.. > (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, > on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) > > > I could also open/close the files for every suspend/resume/processStopped, > though that seems too lame. > > > Another idea, that I don't really like, is to never optimize and > ignore the registers and just use the stack. > I rarely optimize, but depending on that seems bad. > > > Your "safe points" proposal would also make this work, though > I'd rather not wait for that. > > > ? > > Ok to add the two integers all the time? > Ok to either depend on the record layout in C, or to always pass the integers around? > > > Thanks, > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 16 18:40:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Dec 2009 17:40:52 +0000 Subject: [M3devel] pthread/Interix In-Reply-To: <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> References: , <2110C1BC-69DD-44E9-8EDF-D41CFE79F5D1@cs.purdue.edu> , <8F498B32-2D6D-4109-A261-ED47AA7C981E@cs.purdue.edu> Message-ID: There are no public suspend/resume primitives exposed. You can see in the debugger what happens. The signal handling thread calls NtSuspendThread/NtResumeThread. I suppose there is a chance they use the target thread's stack to hold the full previous context, I can dig in the debugger and see. I don't think what I have is too awful though. You see the test_interix.c file? I believe Cygwin does similar, though in that case the thread probably doesn't have the constrained access and you can use the public Win32 GetCurrentThread/DuplicateHandle/SuspendThread/ResumeThread functions. Remember how I had that turning of pthread_self into GetThreadForThis, GetThreadForThat? e.g. one is pthread_self, the other is GetCurrentThread/DuplicateHandle. That might come back. - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 12:08:09 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 16 Dec 2009, at 11:49, Jay K wrote:Signals are handled by a separate thread suspending the target thread and setting the context to run the signal handler. Therefore the state is on that thread's stack, not discoverable. Interesting, this is exactly the way Mach does signals (which is why we use the Mach suspend/resume primitives for Darwin/OSX). If that is how they work, then can't you use the suspend/resume primitives directly? There is only single parameter signal handlers. Normally we could suspend/resume the thread "directly" but the thread is I think created by an outside process and we don't have sufficient access. There is a handle with sufficient access, used by that signal handling thread, but it isn't accessible either. That is what is particularly unfortunate. I think putting the two files in unconditionally and passing to the various functions, plus one other #ifdefed function "OpenInterixFiles" is a reasonable compromise. I've coded it up, haven't compiled/tested yet. An improvement would be to use the (normally) zero sized record and pass that to the C code instead, not wasting the storage on othe platforms. (A direct suspend/resume/getcontext solution will be good for Cygwin I'm sure.) - Jay Subject: Re: pthread/Interix From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 11:40:56 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I really dislike this... just for a broken platform... Is there really no way to know that the context on is not on the stack somewhere? On 16 Dec 2009, at 10:36, Jay K wrote:[again, expect a bounce, but the mail does get through] Tony, for Interix, suspend/resume thread can be achieved writing to a file. Getting a suspended thread's registers can be gotten reading from a file. (I believe the same thing works on Solaris.) It appears to be intended for debuggers. I can see that it works well. I doubt that a thread's context is on a signal handler's stack. I propose: ActState = { Starting, Started, Stopping, Stopped }; REVEAL Activation = UNTRACED BRANDED REF RECORD frame: ADDRESS := NIL; (* exception handling support *) handle: pthread_t := NIL; (* LL = activeMu; thread handle *) statusFile: int := -1; (* for Interix *) controlFile: int := -1; (* for Interix *) (* C code knows the structure above this point *) ... END; ThreadPThread.h: typedef struct _Activation_t { void* frame; void* pthread; int statusFile; /* for Interix */ int controlFile; /* for Interix */ } Activation_t; and then whereever we pass act.handle off to C code, pass act instead. frame is kept first so that it is offset 0 in case that gives codegen efficiencies on the often used push/popframe. The other three are moved up to the top to reduce maintainence of ThreadPThread.h. I assume "branding" doesn't introduce data in the record. I'd have to check the codegen to verify frame is at offset 0. #ifdef code will open the files. Modula-3 code can check if the files are >= 0 and close them, or it can be a call out to #ifdefed C. An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile. (as VAR for initialization). That is less fragile and less extensible. I'm fine with that approach too. As well though, I was wondering, maybe we should have: common/InterixThreadState.i3 T = RECORD END; (* zero size? *) interix/InterixThreadState.i3 T = RECORD statusFile, controlFile := -1; END; and then put InterixThreadState.T in Activation. That way saving the other platforms from spending the space. Just two integers, not much, but in principle.. (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice, on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.) I could also open/close the files for every suspend/resume/processStopped, though that seems too lame. Another idea, that I don't really like, is to never optimize and ignore the registers and just use the stack. I rarely optimize, but depending on that seems bad. Your "safe points" proposal would also make this work, though I'd rather not wait for that. ? Ok to add the two integers all the time? Ok to either depend on the record layout in C, or to always pass the integers around? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Wed Dec 16 21:48:02 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 16 Dec 2009 12:48:02 -0800 (PST) Subject: [M3devel] Oops, forgot to ask Message-ID: <351872.44455.qm@web56806.mail.re3.yahoo.com> Hi Gang, 0 - CARDINALs are an integral type defined by the language spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, a change was made to CM3 to extend the language it recognizes beyond the original language spec (SPWM3), now CM3 understands a LONGINT. Was there a corresponding LONGCARD defined? Can is use all 64-bits, or is it restricted to 63, like the CARDINAL is only 31-bits. 1 - How does one write a WIDECHAR literal? Are WIDECHAR currently only 16-bits? If so they are limited to only the basic multilingual plane (BMP). Unicode characters are 20-bits, which is why encodings such as USC-32 exist. If a WIDECHAR is only 16-bits, are they encoded as UTF-16, which is a similar scheme to UTF-8? If they are currently only 16-bits, are there plans to expand it to fully support unicode character encodings? 2 - Recently there was discussion about creating a new type, that is halfway a REFANY, and halfway a value itself. I myself dislike unions, and fortran equivalences, and any other aliasing techniques, but if the compiler supports it, we should document it. What was it finally called? How does one declare an item of this type? How does one use it? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Wed Dec 16 22:31:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 16:31:00 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > Hi Gang, > > 0 - CARDINALs are an integral type defined by the language > spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > a change was made to CM3 to extend the language it recognizes > beyond the original language spec (SPWM3), now CM3 understands > a LONGINT. > > Was there a corresponding LONGCARD defined? No. But you can write: [0L..LAST(LONGINT)] just as CARDINAL=[0..LAST(INTEGER)] > Can is use all 64-bits, or is it restricted to 63, like > the CARDINAL is only 31-bits. 63 bits, since its underlying base type is LONGINT. > 1 - How does one write a WIDECHAR literal? Are WIDECHAR > currently only 16-bits? If so they are limited to only > the basic multilingual plane (BMP). Unicode characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are currently > only 16-bits, are there plans to expand it to fully support > unicode character encodings? I don't know... ? Probably should. > 2 - Recently there was discussion about creating a new type, > that is halfway a REFANY, and halfway a value itself. I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > we should document it. > > What was it finally called? > How does one declare an item of this type? > How does one use it? There is no new type like this. But, there is provision in the current implementation of the run-time system to ignore any reference value that has a low-bit set. The only way to use it is to LOOPHOLE values with low-bit set into REFANY. TYPECODE(r) for such tagged values returns what would be TYPECODE(REFANY) (but that expression is a compile-time error to write). So, anyone wanting to compare the typecode must use RT0.RefanyTypecode. The implications of all of this are that tagged REFANYs are implementation-dependent, and can only be used with the unsafe LOOPHOLE. In other words, it is not part of the language definition. And, the implementation may not support it in future... > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From dabenavidesd at yahoo.es Wed Dec 16 22:47:41 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Dec 2009 21:47:41 +0000 (GMT) Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <189565.77906.qm@web23601.mail.ird.yahoo.com> Hi Peter and all: I know think MAX(CARDINAL) should be of value 2^31 - 1 in 32 bits platforms.. There is no LONGCARD. If you want to perform unsigned arithmetic operations you can use WORD an you will have 2^32 values or 2^64 in 32 and 64 bits platform correspondent. Concerning INTEGER historically has been 32 bits in 32 bits word size platforms and (by now) 64 bits in 64 bits platforms. LONGINT is tought to be 64 bit in supported platforms (NT386 integrated backend doesn't have it yet). So that Another note about historical type changes I could add is that Math interface to C native library its function return types were once REAL but now are LONGREAL. You can convert LONGREAL to REAL values doing FLOAT(Math.Degree, REAL) for code expecting REAL values; I know WIDECHAR is an additional representation of TEXT in such a case you want to pop WIDECHAR values you will get it from Text interface, all supported platforms have it, I guess the intended use is related to interface native C types and besides the UTF-8 Java Virtual Machine standard internal codification (Modula-3 doesn't enforce that, so there could be an implementation with such encoding I think, said that, so far now, CM3 is not UTF-8 coded as I know) What I understood about having BRANDED REF is to allow C (calloc) capability of having REF values dynamically allocated in stack memory, allowing speed up in programs that use that (calloc C correspondent). I don't about how does affect type system tough, I mean following Modula-3 BRANDED OBJECT type objects have nominal type equivalence (different from default structural type equivalence) it should be the same for BRANDED REF I think thats all I know for know, hope it helps --- El mi?, 16/12/09, Peter Eiserloh escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Oops, forgot to ask > Para: "M3Devel" > Fecha: mi?rcoles, 16 de diciembre, 2009 15:48 > Hi Gang, > > 0 - CARDINALs are an integral type defined by the language > spec to be from 0 (zero) to MAXINT (not MAXCARD). > Recently, > a change was made to CM3 to extend the language it > recognizes > beyond the original language spec (SPWM3), now CM3 > understands > a LONGINT. > > Was there a corresponding LONGCARD defined? > Can is use all 64-bits, or is it restricted to 63, like > the CARDINAL is only 31-bits. > > > 1 - How does one write a WIDECHAR literal? Are > WIDECHAR > currently only 16-bits? If so they are limited to > only > the basic multilingual plane (BMP). Unicode > characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are > currently > only 16-bits, are there plans to expand it to fully support > > unicode character encodings? > > > 2 - Recently there was discussion about creating a new > type, > that is halfway a REFANY, and halfway a value itself. > I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > > we should document it. > > What was it finally called? > How does one declare an item of this type? > How does one use it? > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh > > | > +--------------------------------------------------------+ > > > > From rodney_bates at lcwb.coop Wed Dec 16 23:56:55 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2009 16:56:55 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> Message-ID: <4B2965B7.6040304@lcwb.coop> Tony Hosking wrote: > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > >> Hi Gang, >> >> 0 - CARDINALs are an integral type defined by the language >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, >> a change was made to CM3 to extend the language it recognizes >> beyond the original language spec (SPWM3), now CM3 understands >> a LONGINT. >> >> Was there a corresponding LONGCARD defined? >> > > No. But you can write: > > [0L..LAST(LONGINT)] > > just as > > CARDINAL=[0..LAST(INTEGER)] > Actually, the line above was once true, long long ago, when dinosaurs roamed unfettered. CARDINAL was changed to be "just like" (but not equal to) [0..LAST(INTEGER)]. This would have been maybe early 1990s. It took me years to figure out what this actually meant, and more years to figure out why, but I believe I now know. CARDINAL is not an equal type to [0..LAST(INTEGER)], but otherwise has all the same properties. This makes the two mutually assignable, which is close enough to equal to not matter in most contexts. The exact consequences follow from other language rules. The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of machines with different values of LAST(INTEGER)), because the numeric value of LAST(INTEGER) is part of the expanded type. The one place this matters is if you use pickles to transfer data between machines of different word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash of the complete, expanded type definition) is different on the two machines, and values of or containing this type cannot be transferred. Exact type signature matches are used in pickles to find corresponding types when reading. But pickles handle different sized INTEGER values fine, expanding/shortening as needed. Being a leaf in a type definition, INTEGER is always the same type on any machine. So CARDINAL was changed to be its own unique type too, so it would be possible also to transfer CARDINAL values in pickles between different word sizes. So, we really should have a LONGCARD, parallel to CARDINAL. Note that this also affects network objects, which use pickles to transfer values of the objects. > > >> Can is use all 64-bits, or is it restricted to 63, like >> the CARDINAL is only 31-bits. >> > > 63 bits, since its underlying base type is LONGINT. > > > >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> >> > > > From hendrik at topoi.pooq.com Thu Dec 17 00:13:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Dec 2009 18:13:49 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <20091216231349.GB15089@topoi.pooq.com> On Wed, Dec 16, 2009 at 12:48:02PM -0800, Peter Eiserloh wrote: > > 2 - Recently there was discussion about creating a new type, > that is halfway a REFANY, and halfway a value itself. I > myself dislike unions, and fortran equivalences, and any > other aliasing techniques, but if the compiler supports it, > we should document it. I too hate C unions and fortran equivalences. They cause program breakage, because they're violently insecure. But that's not that these are. These things are properly type-tagged, and if further it is impossible to get at their contents without checking the proper type-tag. -- hendrik From rodney_bates at lcwb.coop Thu Dec 17 00:35:29 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2009 17:35:29 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <351872.44455.qm@web56806.mail.re3.yahoo.com> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> Message-ID: <4B296EC1.1080407@lcwb.coop> Peter Eiserloh wrote: > Hi Gang, > > > > 1 - How does one write a WIDECHAR literal? Are WIDECHAR > currently only 16-bits? If so they are limited to only > the basic multilingual plane (BMP). Put a 'W' or 'w' immediately before the opening single quote of a character literal, and it becomes a WIDECHAR literal. It has type WIDECHAR, allows characters with 16-bit codes, and also allows 16-bit octal and hex escapes. You can do the same with TEXT literals, but there is no such thing as "WIDETEXT". There is only one type TEXT and it can contain any characters in the 16-bit range. The internal representation has many options, dynamically chosen, and part or all of the value may be represented using only 8 bits per character, if the character values permit. Normally, this is all hidden. > Unicode characters > are 20-bits, which is why encodings such as USC-32 exist. > If a WIDECHAR is only 16-bits, are they encoded as UTF-16, > which is a similar scheme to UTF-8? If they are currently > only 16-bits, are there plans to expand it to fully support > unicode character encodings? > There have been some heated wars in this list over how to represent characters in the 16- and 20- bit ranges, with no consensus, that I saw. It is confused by the fact that you can easily put different representations into the same data type, without language changes. I tend to favor fixed-size representations for in-memory program variables, to preserve constant-time subscripted access. But the variable sized representations appear to allow certain common cases to be handled by unmodified source code, written originally for only 8-bit characters. > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From jay.krell at cornell.edu Thu Dec 17 01:52:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Dec 2009 00:52:06 +0000 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2965B7.6040304@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, <4B2965B7.6040304@lcwb.coop> Message-ID: "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. (Actually it would have been useful long ago.) I really think "long" is a dumb name.. There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. - Jay > Date: Wed, 16 Dec 2009 16:56:55 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Oops, forgot to ask > > Tony Hosking wrote: > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > >> Hi Gang, > >> > >> 0 - CARDINALs are an integral type defined by the language > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > >> a change was made to CM3 to extend the language it recognizes > >> beyond the original language spec (SPWM3), now CM3 understands > >> a LONGINT. > >> > >> Was there a corresponding LONGCARD defined? > >> > > > > No. But you can write: > > > > [0L..LAST(LONGINT)] > > > > just as > > > > CARDINAL=[0..LAST(INTEGER)] > > > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in > pickles > between different word sizes. > > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > >> the CARDINAL is only 31-bits. > >> > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > >> > >> > >> > >> +--------------------------------------------------------+ > >> | Peter P. Eiserloh | > >> +--------------------------------------------------------+ > >> > >> > >> > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 17 02:06:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 20:06:52 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2965B7.6040304@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> Message-ID: <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> This does not make sense: Here is the compiler's definition of the builtin CARDINAL type: MODULE Card; IMPORT SubrangeType, Target, TInt, Tipe, Int; PROCEDURE Initialize () = BEGIN T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); Tipe.Define ("CARDINAL", T, TRUE); END Initialize; BEGIN END Card. Notice that it is a subrange type [0..LAST(INTEGER)]. 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 16 Dec 2009, at 17:56, Rodney M. Bates wrote: > Tony Hosking wrote: >> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: >> >> >>> Hi Gang, >>> >>> 0 - CARDINALs are an integral type defined by the language >>> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, >>> a change was made to CM3 to extend the language it recognizes >>> beyond the original language spec (SPWM3), now CM3 understands >>> a LONGINT. >>> Was there a corresponding LONGCARD defined? >>> >> >> No. But you can write: >> >> [0L..LAST(LONGINT)] >> >> just as >> >> CARDINAL=[0..LAST(INTEGER)] >> > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in pickles > between different word sizes. > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > >> >> >>> Can is use all 64-bits, or is it restricted to 63, like >>> the CARDINAL is only 31-bits. >>> >> >> 63 bits, since its underlying base type is LONGINT. >> >> >> >>> >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> >>> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 17 02:10:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 20:10:14 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, <4B2965B7.6040304@lcwb.coop> Message-ID: On 16 Dec 2009, at 19:52, Jay K wrote: > "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? > > > See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. > (Actually it would have been useful long ago.) LONGINT could be 128 bits for all its definition cares. It is just something usually (not always) bigger than an INTEGER. > I really think "long" is a dumb name.. > There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. Now these are dumb names because they wire in the size of the value. In Modula-3 INTEGER is a natural (i.e., word-size) value. > > > - Jay > > > > Date: Wed, 16 Dec 2009 16:56:55 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Oops, forgot to ask > > > > Tony Hosking wrote: > > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > > > > >> Hi Gang, > > >> > > >> 0 - CARDINALs are an integral type defined by the language > > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > > >> a change was made to CM3 to extend the language it recognizes > > >> beyond the original language spec (SPWM3), now CM3 understands > > >> a LONGINT. > > >> > > >> Was there a corresponding LONGCARD defined? > > >> > > > > > > No. But you can write: > > > > > > [0L..LAST(LONGINT)] > > > > > > just as > > > > > > CARDINAL=[0..LAST(INTEGER)] > > > > > Actually, the line above was once true, long long ago, when dinosaurs > > roamed unfettered. CARDINAL was changed to be "just like" > > (but not equal to) [0..LAST(INTEGER)]. This would have been > > maybe early 1990s. > > > > It took me years to figure out what this actually meant, and more > > years to figure out why, but I believe I now know. CARDINAL is not an > > equal type to [0..LAST(INTEGER)], but otherwise has all the same > > properties. This makes the two mutually assignable, which is close > > enough to equal to not matter in most contexts. The exact consequences > > follow from other language rules. > > > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > > machines with different values of LAST(INTEGER)), because the numeric > > value of LAST(INTEGER) is part of the expanded type. The one place this > > matters is if you use pickles to transfer data between machines of different > > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > > of the complete, expanded type definition) is different on the two machines, > > and values of or containing this type cannot be transferred. Exact type > > signature matches are used in pickles to find corresponding types when > > reading. > > > > But pickles handle different sized INTEGER values fine, expanding/shortening > > as needed. Being a leaf in a type definition, INTEGER is always the same > > type on any machine. So CARDINAL was changed to be its own unique > > type too, so it would be possible also to transfer CARDINAL values in > > pickles > > between different word sizes. > > > > So, we really should have a LONGCARD, parallel to CARDINAL. > > > > Note that this also affects network objects, which use pickles to transfer > > values of the objects. > > > > > > > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > > >> the CARDINAL is only 31-bits. > > >> > > > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > > > > > >> > > >> > > >> > > >> +--------------------------------------------------------+ > > >> | Peter P. Eiserloh | > > >> +--------------------------------------------------------+ > > >> > > >> > > >> > > >> > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 17 02:55:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Dec 2009 01:55:15 +0000 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <351872.44455.qm@web56806.mail.re3.yahoo.com>, , <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>, , <4B2965B7.6040304@lcwb.coop>, , Message-ID: These would be "base" types and people would have to pick and chose their own typedefs to suit their needs. Imho the idea of a "natural" size is a nice theory but it turns out that "we" (in the larger software world) are stuck with the exact sizes as they happen to have been for a while. C int will always be 32 bits. Growing it will break too much code. Even if processors get natural 128 bit integers, they will still always have to deal efficiently with 32 bit integers because 32 bit integers won't go away. Ditto now 64bit integers. As well natural is great for a local variable, but as soon as you start allocating things in large numbers, you start wanting the size to not be much larger than is needed and you consider the range you'll actually need..sometimes it is obviously small, sometimes not. If it isn't obviously small then you can err toward a larger type like or int or size_t. If it is obviously a small range and allocated in large number then you'll more seriously consider UINT8 or UINT16. If the range is unavoidably huge then you'll consider floating point or a multiple precision option. Granted, Modula-3 does have "BITS FOR" and subranges. I'm not used to having those. So maybe these types aren't needed since you can build them. The compiler does certainly have these exact types internally though. And the processors generally all have instructions that operate on them (with varying efficiency though). If you consider C, people often have int, long, long long. This is as I said dumb because what will 128 integers be called, "long long long"? "byte", "short", "long" these are just funny informal names. A more mechanical system is INT8, INT16, INT32 or PTRDIFF_T. I grant that there is base integer type with the size of a pointer, that doesn't have the exact number of bits encoded. Perhaps Modula-3 doesn't have such a bad legacy codebase? Perhaps growing INTEGER to 64bits didn't break anything and growing it to 128 won't either? Perhaps persistance is generally pickles and they deal better with this stuff, and not like direct blitting? Anyway, - Jay From: hosking at cs.purdue.edu Date: Wed, 16 Dec 2009 20:10:14 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Oops, forgot to ask On 16 Dec 2009, at 19:52, Jay K wrote: "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. (Actually it would have been useful long ago.) LONGINT could be 128 bits for all its definition cares. It is just something usually (not always) bigger than an INTEGER. I really think "long" is a dumb name.. There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t.. Now these are dumb names because they wire in the size of the value. In Modula-3 INTEGER is a natural (i.e., word-size) value. - Jay > Date: Wed, 16 Dec 2009 16:56:55 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Oops, forgot to ask > > Tony Hosking wrote: > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote: > > > > > >> Hi Gang, > >> > >> 0 - CARDINALs are an integral type defined by the language > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently, > >> a change was made to CM3 to extend the language it recognizes > >> beyond the original language spec (SPWM3), now CM3 understands > >> a LONGINT. > >> > >> Was there a corresponding LONGCARD defined? > >> > > > > No. But you can write: > > > > [0L..LAST(LONGINT)] > > > > just as > > > > CARDINAL=[0..LAST(INTEGER)] > > > Actually, the line above was once true, long long ago, when dinosaurs > roamed unfettered. CARDINAL was changed to be "just like" > (but not equal to) [0..LAST(INTEGER)]. This would have been > maybe early 1990s. > > It took me years to figure out what this actually meant, and more > years to figure out why, but I believe I now know. CARDINAL is not an > equal type to [0..LAST(INTEGER)], but otherwise has all the same > properties. This makes the two mutually assignable, which is close > enough to equal to not matter in most contexts. The exact consequences > follow from other language rules. > > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of > machines with different values of LAST(INTEGER)), because the numeric > value of LAST(INTEGER) is part of the expanded type. The one place this > matters is if you use pickles to transfer data between machines of different > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash > of the complete, expanded type definition) is different on the two machines, > and values of or containing this type cannot be transferred. Exact type > signature matches are used in pickles to find corresponding types when > reading. > > But pickles handle different sized INTEGER values fine, expanding/shortening > as needed. Being a leaf in a type definition, INTEGER is always the same > type on any machine. So CARDINAL was changed to be its own unique > type too, so it would be possible also to transfer CARDINAL values in > pickles > between different word sizes. > > So, we really should have a LONGCARD, parallel to CARDINAL. > > Note that this also affects network objects, which use pickles to transfer > values of the objects. > > > > > > > > >> Can is use all 64-bits, or is it restricted to 63, like > >> the CARDINAL is only 31-bits. > >> > > > > 63 bits, since its underlying base type is LONGINT. > > > > > > > >> > >> > >> > >> +--------------------------------------------------------+ > >> | Peter P. Eiserloh | > >> +--------------------------------------------------------+ > >> > >> > >> > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 7 06:01:41 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 6 Dec 2009 21:01:41 -0800 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> References: , <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> Message-ID: <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> Clarfication, I meant traced heap allocation, the copying of timezone. Could copy to local array then enable switching then alloc/copy. But what I did should be ok. - Jay (phone) On Dec 6, 2009, at 11:14 AM, Tony Hosking wrote: > On 6 Dec 2009, at 09:29, Jay K wrote: > >> I was thinking of that -- DisableSwitching / EnableSwitching -- but >> can the heap allocation happen while >> switching is disabled? > > Yes, it sure can. DisableSwitching/EnableSwitching is exactly what > is needed whenever you are dealing with libraries that are not > thread safe with the user-level thread-switching. > >> I came up with something a bit hacky but maybe ok. >> >> - Jay >> >> >> Subject: Re: [M3devel] DateBsd.m3 lock usually not needed >> From: hosking at cs.purdue.edu >> Date: Sun, 6 Dec 2009 09:25:58 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> That's what SchedulerPosix (badly named but linked to the old user- >> threads naming) is for.... >> >> 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 6 Dec 2009, at 06:48, Jay K wrote: >> >> It'd be nice if DateBsd.m3 only used a lock with user threads and >> not with pthreads/ntthreads. >> >> - Jay >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 17 03:24:36 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Dec 2009 21:24:36 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: References: <4B2965B7.6040304@lcwb.coop> Message-ID: <20091217022436.GC15937@topoi.pooq.com> On Thu, Dec 17, 2009 at 12:52:06AM +0000, Jay K wrote: > > I really think "long" is a dumb name.. > > There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, > UINT64, and unsigned and signed integers the same size of a pointer, > possibly called INT and UINT, or size_t and ptrdiff_t.. Well, in Modula 3, it probably should something like SIZE and PRTDIFF. -- hendrik From hosking at cs.purdue.edu Thu Dec 17 04:41:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Dec 2009 22:41:29 -0500 Subject: [M3devel] DateBsd.m3 lock usually not needed In-Reply-To: <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> References: , <1FA42EDE-E33B-4388-8717-57D9FCD9A2ED@cs.purdue.edu> <0E1D876C-183D-48C0-85B4-532C266E1C9B@hotmail.com> Message-ID: <0E815D43-FD27-4304-874D-928D96317389@cs.purdue.edu> Yes, heap allocation can happen while switching is disabled. On 7 Dec 2009, at 00:01, jay.krell at cornell.edu wrote: > Clarfication, I meant traced heap allocation, the copying of timezone. Could copy to local array then enable switching then alloc/copy. But what I did should be ok. > > - Jay (phone) > > On Dec 6, 2009, at 11:14 AM, Tony Hosking wrote: > >> On 6 Dec 2009, at 09:29, Jay K wrote: >> >>> I was thinking of that -- DisableSwitching / EnableSwitching -- but can the heap allocation happen while >>> switching is disabled? >> >> Yes, it sure can. DisableSwitching/EnableSwitching is exactly what is needed whenever you are dealing with libraries that are not thread safe with the user-level thread-switching. >> >>> I came up with something a bit hacky but maybe ok. >>> >>> - Jay >>> >>> >>> Subject: Re: [M3devel] DateBsd.m3 lock usually not needed >>> From: hosking at cs.purdue.edu >>> Date: Sun, 6 Dec 2009 09:25:58 -0500 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> That's what SchedulerPosix (badly named but linked to the old user-threads naming) is for.... >>> >>> 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 6 Dec 2009, at 06:48, Jay K wrote: >>> >>> It'd be nice if DateBsd.m3 only used a lock with user threads and not with pthreads/ntthreads. >>> >>> - Jay >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 17 16:08:41 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 09:08:41 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> Message-ID: <4B2A4979.7020401@lcwb.coop> Tony Hosking wrote: > This does not make sense: > > Here is the compiler's definition of the builtin CARDINAL type: > > MODULE Card; > > IMPORT SubrangeType, Target, TInt, Tipe, Int; > > PROCEDURE Initialize () = > BEGIN > T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); CARDINAL is builtin -----------------------------------------------^ > Tipe.Define ("CARDINAL", T, TRUE); > END Initialize; > > BEGIN > END Card. > > > Notice that it is a subrange type [0..LAST(INTEGER)]. > > 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 > And from MODULE SubrangeType: .... PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = VAR b: P := t; BEGIN Seal (a); Seal (b); RETURN (a.builtin = b.builtin) ^ --- builtin property must be the same for type equality AND TInt.EQ (a.min, b.min) AND TInt.EQ (a.max, b.max) AND Type.IsEqual (a.baseType, b.baseType, x); END EqualChk; ... PROCEDURE Parse (): Type.T = TYPE TK = Token.T; VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); Programmer-defined subrange is not builtin -- ^ BEGIN Match (TK.tLBRACKET); p.minE := Expr.Parse (); Match (TK.tDOTDOT); p.maxE := Expr.Parse (); Match (TK.tRBRACKET); RETURN p; END Parse; This program: MODULE Card EXPORTS Main ; TYPE C = CARDINAL ; TYPE D = [ 0 .. LAST ( INTEGER ) ] ; PROCEDURE DP ( VAR DPF : D ) = BEGIN DPF := 0 END DP ; PROCEDURE CP ( VAR CPF : C ) = BEGIN CPF := 0 END CP ; PROCEDURE Try ( ) = VAR CV : C ; VAR DV : D ; BEGIN CP ( CV ) ; CP ( DV ) <--- line 20 ; DP ( CV ) ; DP ( DV ) END Try ; BEGIN Try ( ) END Card . Gives these errors: rodney at allegheny:~/proj/m3/exp/card/src$ cm3 --- building in ../AMD64_LINUX --- new source -> compiling Card.m3 "../src/Card.m3", line 20: incompatible types (CPF) "../src/Card.m3", line 21: incompatible types (DPF) 2 errors encountered compilation failed => not building program "prog" Fatal Error: package build failed From hosking at cs.purdue.edu Thu Dec 17 17:12:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Dec 2009 11:12:26 -0500 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <4B2A4979.7020401@lcwb.coop> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> <4B2A4979.7020401@lcwb.coop> Message-ID: <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> Aha! Thanks Rodney. Do we have any use-cases for LONGCARD? On 17 Dec 2009, at 10:08, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> This does not make sense: >> Here is the compiler's definition of the builtin CARDINAL type: >> MODULE Card; >> IMPORT SubrangeType, Target, TInt, Tipe, Int; >> PROCEDURE Initialize () = >> BEGIN >> T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); > > CARDINAL is builtin -----------------------------------------------^ > >> Tipe.Define ("CARDINAL", T, TRUE); >> END Initialize; >> BEGIN >> END Card. >> Notice that it is a subrange type [0..LAST(INTEGER)]. >> 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 > > And from MODULE SubrangeType: > > .... > > PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = > VAR b: P := t; > BEGIN > Seal (a); Seal (b); > RETURN (a.builtin = b.builtin) > > ^ --- builtin property must be the same for type equality > > AND TInt.EQ (a.min, b.min) > AND TInt.EQ (a.max, b.max) > AND Type.IsEqual (a.baseType, b.baseType, x); > END EqualChk; > > ... > > PROCEDURE Parse (): Type.T = > TYPE TK = Token.T; > VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); > > Programmer-defined subrange is not builtin -- ^ > > BEGIN > Match (TK.tLBRACKET); > p.minE := Expr.Parse (); > Match (TK.tDOTDOT); > p.maxE := Expr.Parse (); > Match (TK.tRBRACKET); > RETURN p; > END Parse; > > This program: > > MODULE Card EXPORTS Main > > ; TYPE C = CARDINAL > ; TYPE D = [ 0 .. LAST ( INTEGER ) ] > > ; PROCEDURE DP ( VAR DPF : D ) > = BEGIN > DPF := 0 > END DP > ; PROCEDURE CP ( VAR CPF : C ) > = BEGIN > CPF := 0 > END CP > > ; PROCEDURE Try ( ) > = VAR CV : C > ; VAR DV : D > ; BEGIN > CP ( CV ) > ; CP ( DV ) <--- line 20 > ; DP ( CV ) > ; DP ( DV ) > END Try > > ; BEGIN > Try ( ) > END Card -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Thu Dec 17 17:18:32 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 17 Dec 2009 08:18:32 -0800 (PST) Subject: [M3devel] INTEGER vice INT32 Message-ID: <213164.34773.qm@web56804.mail.re3.yahoo.com> Hi Tony, Both Jay, and yourself have valid points. One can classify the two kinds of types, as implicit, and explicit. More specifically, INTEGER is implicit, and is useful for in-memory representation. This was especially important when machine registers were very different between machines. Very few remember the days of 18-bit words, with 9-bit bytes (thank you!). An implicit type is very useful, when you are not worried about external representation and all one needs is the logical behavior of the type, independent of the particular machine on which one may currently be. Explicit types are much more useful, if not imperative, when defining data types for external storage (in files, or network protocols). For binary file IO many people take a naive approach, and simply overlay a data structure onto the file stream. This ignores the potential difference in sizes of implicit types, and their endianess. A more careful method of doing binary files, is to distinguish the external from the internal representation, and have procedures to do the IO a field at a time. See binIO. Back in the late 1980's, and early 1990s, I had an Amiga computer, and had two different "C" compilers: Aztec, C and SAS/C. The Aztec compiler int was 16-bits, whereas the SAS/C int was 32 bits. As you can imagine this caused all sorts of havoc. The Amiga system includes were rewritten with somewhat more explicit types. These were macros such as ULONG, SLONG, USHORT, SSHORT, UBYTE, and SBYTE. This illustrates the importance of explicit types. Both implicit and explicit types have their place. Peter Date: Wed, 16 Dec 2009 20:10:14 -0500 From: Tony Hosking Subject: Re: [M3devel] Oops, forgot to ask To: Jay K Cc: m3devel Message-ID: Content-Type: text/plain; charset="us-ascii" >On 16 Dec 2009, at 19:52, Jay K wrote: > >> "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 >bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? >> >> >> See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. >> (Actually it would have been useful long ago.) > >LONGINT could be 128 bits for all its definition cares. It is just >something usually (not always) bigger than an INTEGER. > >> I really think "long" is a dumb name.. >> There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, >UINT64, and unsigned and signed integers the same size of a pointer, >possibly called INT and UINT, or size_t and ptrdiff_t.. > >Now these are dumb names because they wire in the size of the value. > >In Modula-3 INTEGER is a natural (i.e., word-size) value. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From hosking at cs.purdue.edu Thu Dec 17 17:30:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Dec 2009 11:30:47 -0500 Subject: [M3devel] INTEGER vice INT32 In-Reply-To: <213164.34773.qm@web56804.mail.re3.yahoo.com> References: <213164.34773.qm@web56804.mail.re3.yahoo.com> Message-ID: <92DD86C0-2379-49D0-87B6-DABF67AF3D45@cs.purdue.edu> But we *do* have explicit types in Modula-3. Subranges and BITS FOR let us pretty much do everything we want (the current implementation restrictions are in using underlying in-memory representations for subranges that round to the nearest byte size). 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 17 Dec 2009, at 11:18, Peter Eiserloh wrote: > Hi Tony, > > Both Jay, and yourself have valid points. > > One can classify the two kinds of types, as implicit, and > explicit. > > More specifically, INTEGER is implicit, and is useful for > in-memory representation. This was especially important > when machine registers were very different between machines. > Very few remember the days of 18-bit words, with 9-bit > bytes (thank you!). An implicit type is very useful, > when you are not worried about external representation > and all one needs is the logical behavior of the type, > independent of the particular machine on which one may > currently be. > > Explicit types are much more useful, if not imperative, > when defining data types for external storage (in files, > or network protocols). > > For binary file IO many people take a naive approach, and > simply overlay a data structure onto the file stream. > This ignores the potential difference in sizes of implicit > types, and their endianess. A more careful method of > doing binary files, is to distinguish the external from > the internal representation, and have procedures to do > the IO a field at a time. See binIO. > > Back in the late 1980's, and early 1990s, I had an Amiga > computer, and had two different "C" compilers: Aztec, C > and SAS/C. The Aztec compiler int was 16-bits, whereas > the SAS/C int was 32 bits. As you can imagine this caused > all sorts of havoc. The Amiga system includes were > rewritten with somewhat more explicit types. These were > macros such as ULONG, SLONG, USHORT, SSHORT, UBYTE, and > SBYTE. > > This illustrates the importance of explicit types. > Both implicit and explicit types have their place. > > > Peter > > > > Date: Wed, 16 Dec 2009 20:10:14 -0500 > From: Tony Hosking > Subject: Re: [M3devel] Oops, forgot to ask > To: Jay K > Cc: m3devel > Message-ID: > Content-Type: text/plain; charset="us-ascii" > >> On 16 Dec 2009, at 19:52, Jay K wrote: >> >>> "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 >> bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER? >>> >>> >>> See..LONGINT is only useful in this brief period where we still have 32bit INTEGER. >>> (Actually it would have been useful long ago.) >> >> LONGINT could be 128 bits for all its definition cares. It is just >> something usually (not always) bigger than an INTEGER. >> >>> I really think "long" is a dumb name.. >>> There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, >> UINT64, and unsigned and signed integers the same size of a pointer, >> possibly called INT and UINT, or size_t and ptrdiff_t.. >> >> Now these are dumb names because they wire in the size of the value. >> >> In Modula-3 INTEGER is a natural (i.e., word-size) value. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Thu Dec 17 18:46:31 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Thu, 17 Dec 2009 09:46:31 -0800 (PST) Subject: [M3devel] Widechar literals [Was Re: Oops, forgot to ask (Rodney M. Bates) Message-ID: <220296.21268.qm@web56805.mail.re3.yahoo.com> Thank you Rodney. So, if I wanted to represent GREEK SMALL LETTER ALPHA: CONST GreekSmallAlpha = W'03B1'; (* WIDECHAR *) I may not have understood properly. This is not explained in http://www.opencm3.net/doc/reference/texts.html There should be a way of specifying that this is a hex value. Octal values are of course introduced with a backslash followed by a three octal digits. I would have liked to see something like a backslash followed by an x or X and four hexadecimal digits to give the 16-bit value. As in W'\x03B1'. If we were to ever get full unicode support (20-bits) we may need an escape for it. The unicode standard lists code points as in "U+003B1", so a similar escape may look like W'\u003B1'. Next question: are the hexadecimal digits case insensitive? Peter >Date: Wed, 16 Dec 2009 17:35:29 -0600 >From: "Rodney M. Bates" >Subject: Re: [M3devel] Oops, forgot to ask >To: M3Devel >Message-ID: <4B296EC1.1080407 at lcwb.coop> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Peter Eiserloh wrote: >> Hi Gang, >> >> >> >> 1 - How does one write a WIDECHAR literal? Are WIDECHAR >> currently only 16-bits? If so they are limited to only >> the basic multilingual plane (BMP). > >Put a 'W' or 'w' immediately before the opening single >quote of a character literal, and it becomes a WIDECHAR >literal. It has type WIDECHAR, allows characters with >16-bit codes, and also allows 16-bit octal and hex escapes. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From rodney_bates at lcwb.coop Thu Dec 17 20:30:39 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 13:30:39 -0600 Subject: [M3devel] Widechar literals [Was Re: Oops, forgot to ask (Rodney M. Bates) In-Reply-To: <220296.21268.qm@web56805.mail.re3.yahoo.com> References: <220296.21268.qm@web56805.mail.re3.yahoo.com> Message-ID: <4B2A86DF.3070101@lcwb.coop> If the literal (CHAR or TEXT) is not wide, you can have a backslash followed by exactly 3 octal digits as an escape. Or, backslash, followed by 'x' or 'X', followed by exactly two hex digits. For wide literals (WIDECHAR or TEXT), the number of octal digits is exactly 6 and for hex, exactly four. The hex digits are not case sensitive. The same is true for hex digits in numeric literals too. Peter Eiserloh wrote: > Thank you Rodney. > > So, if I wanted to represent GREEK SMALL LETTER ALPHA: > > CONST > GreekSmallAlpha = W'03B1'; (* WIDECHAR *) > > I may not have understood properly. > > This is not explained in > http://www.opencm3.net/doc/reference/texts.html ^ --- I've put this on my list to fix. > > There should be a way of specifying that this is a > hex value. Octal values are of course introduced > with a backslash followed by a three octal digits. > I would have liked to see something like a backslash > followed by an x or X and four hexadecimal digits > to give the 16-bit value. As in W'\x03B1'. > > If we were to ever get full unicode support (20-bits) > we may need an escape for it. The unicode standard > lists code points as in "U+003B1", so a similar escape > may look like W'\u003B1'. > > > Next question: are the hexadecimal digits case insensitive? > > > > Peter > > >> Date: Wed, 16 Dec 2009 17:35:29 -0600 >> From: "Rodney M. Bates" >> Subject: Re: [M3devel] Oops, forgot to ask >> To: M3Devel >> Message-ID: <4B296EC1.1080407 at lcwb.coop> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Peter Eiserloh wrote: >>> Hi Gang, >>> >>> >>> >>> 1 - How does one write a WIDECHAR literal? Are WIDECHAR >>> currently only 16-bits? If so they are limited to only >>> the basic multilingual plane (BMP). >> Put a 'W' or 'w' immediately before the opening single >> quote of a character literal, and it becomes a WIDECHAR >> literal. It has type WIDECHAR, allows characters with >> 16-bit codes, and also allows 16-bit octal and hex escapes. > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > From rodney_bates at lcwb.coop Thu Dec 17 22:29:00 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Dec 2009 15:29:00 -0600 Subject: [M3devel] Oops, forgot to ask In-Reply-To: <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> References: <351872.44455.qm@web56806.mail.re3.yahoo.com> <1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu> <4B2965B7.6040304@lcwb.coop> <3C08F474-9C07-4236-91EF-DA11A1B71D75@cs.purdue.edu> <4B2A4979.7020401@lcwb.coop> <8DA1CC3D-D30A-4AF3-835E-00405A578F13@cs.purdue.edu> Message-ID: <4B2AA29C.5050708@lcwb.coop> The only one I know of is if you want to a pickle or network object with a long field that is nonnegative, but you want its size to be converted between different native word sizes when reading the pickles. Tony Hosking wrote: > Aha! Thanks Rodney. Do we have any use-cases for LONGCARD? > > On 17 Dec 2009, at 10:08, Rodney M. Bates wrote: > >> >> >> Tony Hosking wrote: >>> This does not make sense: >>> Here is the compiler's definition of the builtin CARDINAL type: >>> MODULE Card; >>> IMPORT SubrangeType, Target, TInt, Tipe, Int; >>> PROCEDURE Initialize () = >>> BEGIN >>> T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE); >> >> CARDINAL is builtin -----------------------------------------------^ >> >>> Tipe.Define ("CARDINAL", T, TRUE); >>> END Initialize; >>> BEGIN >>> END Card. >>> Notice that it is a subrange type [0..LAST(INTEGER)]. >>> 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 >> >> And from MODULE SubrangeType: >> >> .... >> >> PROCEDURE EqualChk (a: P; t: Type.T; x: Type.Assumption): BOOLEAN = >> VAR b: P := t; >> BEGIN >> Seal (a); Seal (b); >> RETURN (a.builtin = b.builtin) >> >> ^ --- builtin property must be the same for type equality >> >> AND TInt.EQ (a.min, b.min) >> AND TInt.EQ (a.max, b.max) >> AND Type.IsEqual (a.baseType, b.baseType, x); >> END EqualChk; >> >> ... >> >> PROCEDURE Parse (): Type.T = >> TYPE TK = Token.T; >> VAR p: P := New (TInt.Zero, TInt.MOne, NIL, FALSE); >> >> Programmer-defined subrange is not builtin -- ^ >> >> BEGIN >> Match (TK.tLBRACKET); >> p.minE := Expr.Parse (); >> Match (TK.tDOTDOT); >> p.maxE := Expr.Parse (); >> Match (TK.tRBRACKET); >> RETURN p; >> END Parse; >> >> This program: >> >> MODULE Card EXPORTS Main >> >> ; TYPE C = CARDINAL >> ; TYPE D = [ 0 .. LAST ( INTEGER ) ] >> >> ; PROCEDURE DP ( VAR DPF : D ) >> = BEGIN >> DPF := 0 >> END DP >> ; PROCEDURE CP ( VAR CPF : C ) >> = BEGIN >> CPF := 0 >> END CP >> >> ; PROCEDURE Try ( ) >> = VAR CV : C >> ; VAR DV : D >> ; BEGIN >> CP ( CV ) >> ; CP ( DV ) <--- line 20 >> ; DP ( CV ) >> ; DP ( DV ) >> END Try >> >> ; BEGIN >> Try ( ) >> END Card > From jay.krell at cornell.edu Fri Dec 18 19:04:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 18:04:27 +0000 Subject: [M3devel] cas/casp? Message-ID: Tony is this right? conceptually: result := CAS(VAR destination, compare, exchange) old := destination if old := compare then destination = exchange return old bool result := CASP(VAR destination, compare, exchange) P for predicate aka returning bool old := destination if old = compare then destination := exchange return true return false I'm pretty sure it is. I'll have this for 16 bit and 32 bit values shortly, for now requiring a recent Microsoft compiler and it generates function calls. But inlining should be easy enough. And then 8bit and 64bit. Also this will probably not work on 386 or 486 but require Pentium or somesuch. I don't know when various instructions were introduced but I know 386 is much poorer here than modern processors. I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t and not e.g. floating point. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 18 19:23:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 18:23:59 +0000 Subject: [M3devel] cas/casp? In-Reply-To: References: Message-ID: Nevermind. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Fri, 18 Dec 2009 18:04:27 +0000 Subject: [M3devel] cas/casp? Tony is this right? conceptually: result := CAS(VAR destination, compare, exchange) old := destination if old := compare then destination = exchange return old bool result := CASP(VAR destination, compare, exchange) P for predicate aka returning bool old := destination if old = compare then destination := exchange return true return false I'm pretty sure it is. I'll have this for 16 bit and 32 bit values shortly, for now requiring a recent Microsoft compiler and it generates function calls. But inlining should be easy enough. And then 8bit and 64bit. Also this will probably not work on 386 or 486 but require Pentium or somesuch. I don't know when various instructions were introduced but I know 386 is much poorer here than modern processors. I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t and not e.g. floating point. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 19:32:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 13:32:57 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: Message-ID: <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. GENERIC INTERFACE Atomic(Rep); IMPORT RTMachine; TYPE T = Rep.T; PROCEDURE MemoryFence(); (* Guarantees explicit memory ordering for otherwise unordered atomics, and for other memory references wrt atomics. Not useful for ordering ordinary memory references, since those may not race and, if they don't race, always appear to be ordered. *) PROCEDURE CompilerFence(); (* Ensures that prior memory operations appear in the instruction stream before subsequent ones, i.e. the compiler is not allowed to reorder around this. This really has only implementation-defined semantics, but it seems to be useful in ensuring ordering with respect to signal handlers and the like. *) PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) PROCEDURE StoreRelease(VAR var: T; val: T); PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) PROCEDURE LoadAcquire(READONLY var: T): T; TYPE Order = { Raw, Acquire, Release, Ordered }; (* "Raw" ==> This operation is unordered, and may become visible to other threads in an order that is constrained only by ordering constraints on other operations. "Release" ==> All prior memory operations (including ordinary assignments) become visible to a an acquire operation on the same object that sees the resulting value. "Acquire" ==> See above. "Ordered" ==> Both acquire and release ordering properties.*) CONST HasCas = RTMachine.HasCas; CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; (* Most architectures provide a way to return the old value. On those that do not, it can be emulated with an additional load, at the expense of wait-freedom or spurious failure. *) CONST HasWeakCas = RTMachine.HasWeakCas; PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; (* Similar to "Cas", but may fail spuriously, and must be wait-free, if provided. *) CONST HasFetchAdd = RTMachine.HasFetchAdd; PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; CONST HasFetchOr = RTMachine.HasFetchOr; PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; CONST HasFetchAnd = RTMachine.HasFetchAnd; PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; END Atomic. On 18 Dec 2009, at 13:04, Jay K wrote: > Tony is this right? > > > conceptually: > > > result := CAS(VAR destination, compare, exchange) > > > old := destination > if old := compare then > destination = exchange > return old > > > bool result := CASP(VAR destination, compare, exchange) > P for predicate aka returning bool > > > old := destination > if old = compare then > destination := exchange > return true > return false > > > I'm pretty sure it is. > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > a recent Microsoft compiler and it generates function calls. > But inlining should be easy enough. > And then 8bit and 64bit. > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > I don't know when various instructions were introduced but I know > 386 is much poorer here than modern processors. > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > and not e.g. floating point. > > > - Jay From jay.krell at cornell.edu Fri Dec 18 20:06:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 19:06:06 +0000 Subject: [M3devel] cas/casp? In-Reply-To: <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Message-ID: oh. I already got it working. ok. Atomic confuses me in a few ways. I find it terribly confusing on Windows that there are separate compiler and memory fences. I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. It makes no sense to me to allow the processor or compiler to reorder but not both. What is weak cas? Is that loadlocked/storecondition and the caller can loop? Um. There is the Windows terminology InterlockedWhatever. There is the gccc builtins. Can we "sound" close to one of them? Or is this based on some other widely known system? And we don't care about older x86 processors like 386?486 I assume? There seem to have been at least two leaps in functionality here. Old Win32 operating systems provide very few interlocked functions. They provide increment and decrement, that only return <0, 0, >0 of the new value. And Exchange. (This is based on the Visual C++ 2.0 winbase.h) All just on 32bit values. Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 13:32:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cas/casp? > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > GENERIC INTERFACE Atomic(Rep); > > IMPORT RTMachine; > > TYPE T = Rep.T; > > PROCEDURE MemoryFence(); > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > for other memory references wrt atomics. Not useful for ordering > ordinary memory references, since those may not race and, if they don't > race, always appear to be ordered. *) > > PROCEDURE CompilerFence(); > (* Ensures that prior memory operations appear in the instruction stream > before subsequent ones, i.e. the compiler is not allowed to reorder > around this. This really has only implementation-defined semantics, but > it seems to be useful in ensuring ordering with respect to signal > handlers and the like. *) > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > PROCEDURE StoreRelease(VAR var: T; val: T); > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > PROCEDURE LoadAcquire(READONLY var: T): T; > > TYPE Order = { Raw, Acquire, Release, Ordered }; > (* "Raw" ==> This operation is unordered, and may become visible to other > threads in an order that is constrained only by ordering constraints > on other operations. > > "Release" ==> All prior memory operations (including ordinary > assignments) become visible to a an acquire operation on the same > object that sees the resulting value. > > "Acquire" ==> See above. > > "Ordered" ==> Both acquire and release ordering properties.*) > > CONST HasCas = RTMachine.HasCas; > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > (* Most architectures provide a way to return the old value. On those that > do not, it can be emulated with an additional load, at the expense of > wait-freedom or spurious failure. *) > > CONST HasWeakCas = RTMachine.HasWeakCas; > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > provided. *) > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > CONST HasFetchOr = RTMachine.HasFetchOr; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > END Atomic. > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > Tony is this right? > > > > > > conceptually: > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > old := destination > > if old := compare then > > destination = exchange > > return old > > > > > > bool result := CASP(VAR destination, compare, exchange) > > P for predicate aka returning bool > > > > > > old := destination > > if old = compare then > > destination := exchange > > return true > > return false > > > > > > I'm pretty sure it is. > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > a recent Microsoft compiler and it generates function calls. > > But inlining should be easy enough. > > And then 8bit and 64bit. > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > I don't know when various instructions were introduced but I know > > 386 is much poorer here than modern processors. > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > and not e.g. floating point. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 20:12:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 14:12:44 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> Message-ID: <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> On 18 Dec 2009, at 14:06, Jay K wrote: > oh. I already got it working. ok. > > Atomic confuses me in a few ways. > > I find it terribly confusing on Windows that there are separate compiler and memory fences. > I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. > It makes no sense to me to allow the processor or compiler to reorder but not both. > > > What is weak cas? It's a CAS that can fail spuriously. i.e., even if the old value was ==. > Is that loadlocked/storecondition and the caller can loop? > > > Um. There is the Windows terminology InterlockedWhatever. > There is the gccc builtins. > Can we "sound" close to one of them? > Or is this based on some other widely known system? The Atomic interface I posted is based on a proposal for the C++ standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html > And we don't care about older x86 processors like 386?486 I assume? > There seem to have been at least two leaps in functionality here. > Old Win32 operating systems provide very few interlocked functions. > They provide increment and decrement, that only return <0, 0, >0 of the new value. > And Exchange. (This is based on the Visual C++ 2.0 winbase.h) > All just on 32bit values. > > Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. > > And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. > > And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. > >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 18 Dec 2009 13:32:57 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] cas/casp? > > > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > > > GENERIC INTERFACE Atomic(Rep); > > > > IMPORT RTMachine; > > > > TYPE T = Rep.T; > > > > PROCEDURE MemoryFence(); > > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > > for other memory references wrt atomics. Not useful for ordering > > ordinary memory references, since those may not race and, if they don't > > race, always appear to be ordered. *) > > > > PROCEDURE CompilerFence(); > > (* Ensures that prior memory operations appear in the instruction stream > > before subsequent ones, i.e. the compiler is not allowed to reorder > > around this. This really has only implementation-defined semantics, but > > it seems to be useful in ensuring ordering with respect to signal > > handlers and the like. *) > > > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > > PROCEDURE StoreRelease(VAR var: T; val: T); > > > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > > PROCEDURE LoadAcquire(READONLY var: T): T; > > > > TYPE Order = { Raw, Acquire, Release, Ordered }; > > (* "Raw" ==> This operation is unordered, and may become visible to other > > threads in an order that is constrained only by ordering constraints > > on other operations. > > > > "Release" ==> All prior memory operations (including ordinary > > assignments) become visible to a an acquire operation on the same > > object that sees the resulting value. > > > > "Acquire" ==> See above. > > > > "Ordered" ==> Both acquire and release ordering properties.*) > > > > CONST HasCas = RTMachine.HasCas; > > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > > (* Most architectures provide a way to return the old value. On those that > > do not, it can be emulated with an additional load, at the expense of > > wait-freedom or spurious failure. *) > > > > CONST HasWeakCas = RTMachine.HasWeakCas; > > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > > provided. *) > > > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > > > CONST HasFetchOr = RTMachine.HasFetchOr; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > END Atomic. > > > > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > > > Tony is this right? > > > > > > > > > conceptually: > > > > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > > > > old := destination > > > if old := compare then > > > destination = exchange > > > return old > > > > > > > > > bool result := CASP(VAR destination, compare, exchange) > > > P for predicate aka returning bool > > > > > > > > > old := destination > > > if old = compare then > > > destination := exchange > > > return true > > > return false > > > > > > > > > I'm pretty sure it is. > > > > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > > a recent Microsoft compiler and it generates function calls. > > > But inlining should be easy enough. > > > And then 8bit and 64bit. > > > > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > > I don't know when various instructions were introduced but I know > > > 386 is much poorer here than modern processors. > > > > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > > and not e.g. floating point. > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 18 20:32:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Dec 2009 19:32:33 +0000 Subject: [M3devel] cas/casp? In-Reply-To: <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> , <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> Message-ID: Ah, ok. btw another "common" primitive is InterlockedCompareExchange"Double". As in InterlockedCompareExchange64 that's been in x86 a while and InterlockedCompareExchange128 that is newer. There are also often alignment requirements for these things, like to not cross cache line boundaries. We're already ok that way? At least for globals? - Jay Subject: Re: [M3devel] cas/casp? From: hosking at cs.purdue.edu Date: Fri, 18 Dec 2009 14:12:44 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 18 Dec 2009, at 14:06, Jay K wrote: oh. I already got it working. ok. Atomic confuses me in a few ways. I find it terribly confusing on Windows that there are separate compiler and memory fences. I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. It makes no sense to me to allow the processor or compiler to reorder but not both. What is weak cas? It's a CAS that can fail spuriously. i.e., even if the old value was ==. Is that loadlocked/storecondition and the caller can loop? Um. There is the Windows terminology InterlockedWhatever. There is the gccc builtins. Can we "sound" close to one of them? Or is this based on some other widely known system? The Atomic interface I posted is based on a proposal for the C++ standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html And we don't care about older x86 processors like 386?486 I assume? There seem to have been at least two leaps in functionality here. Old Win32 operating systems provide very few interlocked functions. They provide increment and decrement, that only return <0, 0, >0 of the new value. And Exchange. (This is based on the Visual C++ 2.0 winbase.h) All just on 32bit values. Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 13:32:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cas/casp? > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > GENERIC INTERFACE Atomic(Rep); > > IMPORT RTMachine; > > TYPE T = Rep.T; > > PROCEDURE MemoryFence(); > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > for other memory references wrt atomics. Not useful for ordering > ordinary memory references, since those may not race and, if they don't > race, always appear to be ordered. *) > > PROCEDURE CompilerFence(); > (* Ensures that prior memory operations appear in the instruction stream > before subsequent ones, i.e. the compiler is not allowed to reorder > around this. This really has only implementation-defined semantics, but > it seems to be useful in ensuring ordering with respect to signal > handlers and the like. *) > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > PROCEDURE StoreRelease(VAR var: T; val: T); > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > PROCEDURE LoadAcquire(READONLY var: T): T; > > TYPE Order = { Raw, Acquire, Release, Ordered }; > (* "Raw" ==> This operation is unordered, and may become visible to other > threads in an order that is constrained only by ordering constraints > on other operations. > > "Release" ==> All prior memory operations (including ordinary > assignments) become visible to a an acquire operation on the same > object that sees the resulting value. > > "Acquire" ==> See above. > > "Ordered" ==> Both acquire and release ordering properties.*) > > CONST HasCas = RTMachine.HasCas; > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > (* Most architectures provide a way to return the old value. On those that > do not, it can be emulated with an additional load, at the expense of > wait-freedom or spurious failure. *) > > CONST HasWeakCas = RTMachine.HasWeakCas; > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > provided. *) > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > CONST HasFetchOr = RTMachine.HasFetchOr; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > END Atomic. > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > Tony is this right? > > > > > > conceptually: > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > old := destination > > if old := compare then > > destination = exchange > > return old > > > > > > bool result := CASP(VAR destination, compare, exchange) > > P for predicate aka returning bool > > > > > > old := destination > > if old = compare then > > destination := exchange > > return true > > return false > > > > > > I'm pretty sure it is. > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > a recent Microsoft compiler and it generates function calls. > > But inlining should be easy enough. > > And then 8bit and 64bit. > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > I don't know when various instructions were introduced but I know > > 386 is much poorer here than modern processors. > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > and not e.g. floating point. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Dec 18 21:19:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Dec 2009 15:19:36 -0500 Subject: [M3devel] cas/casp? In-Reply-To: References: , <6731EAB4-1CF5-44FB-AB9A-8459215DA021@cs.purdue.edu> , <4E9FB1CB-84F2-4F7A-AB66-307A7462B833@cs.purdue.edu> Message-ID: <730B2897-39CC-4719-87E2-1C372FBFD734@cs.purdue.edu> On 18 Dec 2009, at 14:32, Jay K wrote: > Ah, ok. > > btw another "common" primitive is InterlockedCompareExchange"Double". > As in InterlockedCompareExchange64 that's been in x86 a while and InterlockedCompareExchange128 that is newer. > > There are also often alignment requirements for these things, like to not cross cache line boundaries. > We're already ok that way? > At least for globals? I think so. Need to check. > > - Jay > > > Subject: Re: [M3devel] cas/casp? > From: hosking at cs.purdue.edu > Date: Fri, 18 Dec 2009 14:12:44 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > On 18 Dec 2009, at 14:06, Jay K wrote: > > oh. I already got it working. ok. > > Atomic confuses me in a few ways. > > I find it terribly confusing on Windows that there are separate compiler and memory fences. > I'd like there to be a very simple full fence that forces all reads/writes before it to finish before any reads/writes after it, both for the compiler and processor. > > MemoryFence does that. CompilerFence is strictly weaker than MemoryFence. > > It makes no sense to me to allow the processor or compiler to reorder but not both. > > > What is weak cas? > > It's a CAS that can fail spuriously. i.e., even if the old value was ==. > > Is that loadlocked/storecondition and the caller can loop? > > > Um. There is the Windows terminology InterlockedWhatever. > There is the gccc builtins. > Can we "sound" close to one of them? > Or is this based on some other widely known system? > > The Atomic interface I posted is based on a proposal for the C++ standard: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html > > And we don't care about older x86 processors like 386?486 I assume? > There seem to have been at least two leaps in functionality here. > Old Win32 operating systems provide very few interlocked functions. > They provide increment and decrement, that only return <0, 0, >0 of the new value. > And Exchange. (This is based on the Visual C++ 2.0 winbase.h) > All just on 32bit values. > > Later on there is a much larger suite, Exchange, ExchangeAdd, Inc/Dec that return new value, all on 32 bit values. > > And then later, stuff added for 16 values, bit operations, maybe 8 bit values, and, or, xor. I don't think this requires newer processors though. > > And then also at some point InterlockedCompareExchange64 which requires the "newest" processors, but is still quite old. > >From this you can synthesize inc/dec/and/or/xor with loops and that is done with inline functions in winbase.h. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 18 Dec 2009 13:32:57 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] cas/casp? > > > > Hold your horses. I am in the middle of working up a more portable "Atomic" interface along the following lines. We can choose to implement with compiler intrinsics like Word/LongWord (if available), but otherwise will provide a call interface. I envision instantiating for ADDRESS, CHAR, and Word.T. This means CAS/CASP will go away. > > > > GENERIC INTERFACE Atomic(Rep); > > > > IMPORT RTMachine; > > > > TYPE T = Rep.T; > > > > PROCEDURE MemoryFence(); > > (* Guarantees explicit memory ordering for otherwise unordered atomics, and > > for other memory references wrt atomics. Not useful for ordering > > ordinary memory references, since those may not race and, if they don't > > race, always appear to be ordered. *) > > > > PROCEDURE CompilerFence(); > > (* Ensures that prior memory operations appear in the instruction stream > > before subsequent ones, i.e. the compiler is not allowed to reorder > > around this. This really has only implementation-defined semantics, but > > it seems to be useful in ensuring ordering with respect to signal > > handlers and the like. *) > > > > PROCEDURE Store(VAR var: T; val: T); (* No ordering guarantees. *) > > PROCEDURE StoreRelease(VAR var: T; val: T); > > > > PROCEDURE Load(READONLY var: T): T; (* No ordering guarantees. *) > > PROCEDURE LoadAcquire(READONLY var: T): T; > > > > TYPE Order = { Raw, Acquire, Release, Ordered }; > > (* "Raw" ==> This operation is unordered, and may become visible to other > > threads in an order that is constrained only by ordering constraints > > on other operations. > > > > "Release" ==> All prior memory operations (including ordinary > > assignments) become visible to a an acquire operation on the same > > object that sees the resulting value. > > > > "Acquire" ==> See above. > > > > "Ordered" ==> Both acquire and release ordering properties.*) > > > > CONST HasCas = RTMachine.HasCas; > > CONST HasWaitFreeCas = RTMachine.HasWaitFreeCas; > > PROCEDURE Cas(VAR var: T; old, new: T; order := Ordered): T; > > (* Most architectures provide a way to return the old value. On those that > > do not, it can be emulated with an additional load, at the expense of > > wait-freedom or spurious failure. *) > > > > CONST HasWeakCas = RTMachine.HasWeakCas; > > PROCEDURE WeakCas(VAR var: T; old, new: T; order := Ordered): T; > > (* Similar to "Cas", but may fail spuriously, and must be wait-free, if > > provided. *) > > > > CONST HasFetchAdd = RTMachine.HasFetchAdd; > > PROCEDURE FetchAdd(VAR var; incr: T; order := Raw): T; > > > > CONST HasFetchOr = RTMachine.HasFetchOr; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > CONST HasFetchAnd = RTMachine.HasFetchAnd; > > PROCEDURE FetchOr(VAR var; mask: T; order := Raw): T; > > > > END Atomic. > > > > > > On 18 Dec 2009, at 13:04, Jay K wrote: > > > > > Tony is this right? > > > > > > > > > conceptually: > > > > > > > > > result := CAS(VAR destination, compare, exchange) > > > > > > > > > old := destination > > > if old := compare then > > > destination = exchange > > > return old > > > > > > > > > bool result := CASP(VAR destination, compare, exchange) > > > P for predicate aka returning bool > > > > > > > > > old := destination > > > if old = compare then > > > destination := exchange > > > return true > > > return false > > > > > > > > > I'm pretty sure it is. > > > > > > > > > I'll have this for 16 bit and 32 bit values shortly, for now requiring > > > a recent Microsoft compiler and it generates function calls. > > > But inlining should be easy enough. > > > And then 8bit and 64bit. > > > > > > > > > Also this will probably not work on 386 or 486 but require Pentium or somesuch. > > > I don't know when various instructions were introduced but I know > > > 386 is much poorer here than modern processors. > > > > > > > > > I assume only support int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t > > > and not e.g. floating point. > > > > > > > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:30:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:30:47 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. Message-ID: Here is my updated proposal for Modula-3 Atomic Word.T. These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. INTERFACE Atomic; IMPORT Word; TYPE T = Word.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = RTMachine.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:32:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:32:43 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: PS Some of these we probably can implement using existing gcc intrinsics. On 19 Dec 2009, at 18:30, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 00:35:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Dec 2009 18:35:31 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> Typo: FetchXAnd should read FetchAnd. On 19 Dec 2009, at 18:30, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 20 07:44:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Dec 2009 06:44:07 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> References: , <5E433AA1-B048-4C57-A8B0-DE5B63874D06@cs.purdue.edu> Message-ID: There should be a link to the C++ proposal? As well, new idea, I like the idea of source files containing a link to their cvsweb page. Not to the specific version, but something fairly "stable". - Jay From: hosking at cs.purdue.edu Date: Sat, 19 Dec 2009 18:35:31 -0500 To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. Typo: FetchXAnd should read FetchAnd. On 19 Dec 2009, at 18:30, Tony Hosking wrote: Here is my updated proposal for Modula-3 Atomic Word.T. These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. INTERFACE Atomic; IMPORT Word; TYPE T = Word.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = RTMachine.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Dec 20 04:53:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 19 Dec 2009 22:53:17 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <20091220035317.GA22518@topoi.pooq.com> On Sat, Dec 19, 2009 at 06:30:47PM -0500, Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a prototype implementation for the C++ memory model standardization process. At the moment they are not gcc intrinsics, but I expect to see that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. It's not quite clear to me what these Orders mean. In particular, I don't see a clear model for the interaction of 'visibility', 'memory writes' and 'threads'. I can certainly find a ways to understand these words, but I can't be sure I understand them the same way as they are intended. Perhaps I lack context that is provided somewhere. -- hendrik From jay.krell at cornell.edu Sun Dec 20 15:57:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Dec 2009 14:57:32 +0000 Subject: [M3devel] int32 vs. integer in compare result? Message-ID: In m3front\src\misc\CG.m3: PROCEDURE Compare (t: ZType; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; cg.compare (t, Target.Integer.cg_type, op); SPop (2, "Compare"); SPush (Type.Int32); END Compare; compare(input type, output type, operation) The integrated backend ignores the output type. The gcc backend does not. Doesn't it seem like in the above, Target.Integer and Int32 should match? That compare is being asked to return a possibly larger result than the front end expects? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Dec 20 17:44:38 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 20 Dec 2009 10:44:38 -0600 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: Message-ID: <4B2E5476.5000200@lcwb.coop> Tony Hosking wrote: > Here is my updated proposal for Modula-3 Atomic Word.T. > These are based on what we can have implemented from libatomic_ops, a > prototype implementation for the C++ memory model standardization > process. At the moment they are not gcc intrinsics, but I expect to see > that coming as the standard progresses. > > INTERFACE Atomic; > > IMPORT Word; > > TYPE T = Word.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory > locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = RTMachine.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is > affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per > "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with > "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false > while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T; PROCEDURE FetchPlus (VAR var:T; incr: T; order := Sequential): T; Presumably -------------------^? Similarly in all the Fetch* procs. > PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; Presumably ------------------------^ would be more expressive? > PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T; > PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is > affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use > two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise > have no > undefined behavior. *) To be legal on ADDRESS, either another parallel interface or a set of parallel procedures would be needed. Or else, this interface would have to be known to the core language and allow predefined overloading, similar to builtin operators and functions. The syntax could still be that of an interface. I don't think any existing required interfaces do this now. > > END Atomic. > > > 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 > > > > From hosking at cs.purdue.edu Sun Dec 20 19:15:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 13:15:50 -0500 Subject: [M3devel] int32 vs. integer in compare result? In-Reply-To: References: Message-ID: Yes, this seems odd... Of course, the result is supposed to be a Boolean. Will it matter? On 20 Dec 2009, at 09:57, Jay K wrote: > In m3front\src\misc\CG.m3: > > PROCEDURE Compare (t: ZType; op: Cmp) = > BEGIN > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > cg.compare (t, Target.Integer.cg_type, op); > SPop (2, "Compare"); > SPush (Type.Int32); > END Compare; > > > compare(input type, output type, operation) > > The integrated backend ignores the output type. > The gcc backend does not. > > Doesn't it seem like in the above, Target.Integer and Int32 should match? > That compare is being asked to return a possibly larger result than the > front end expects? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 20 20:01:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 14:01:08 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2E5476.5000200@lcwb.coop> References: <4B2E5476.5000200@lcwb.coop> Message-ID: <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> Thanks for the typo fixes. On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > To be legal on ADDRESS, either another parallel interface or a set of parallel > procedures would be needed. Or else, this interface would have to be known to > the core language and allow predefined overloading, similar to builtin operators > and functions. The syntax could still be that of an interface. I don't think > any existing required interfaces do this now. Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: GENERIC INTERFACE Atomic(Rep); TYPE T = Rep.T; TYPE Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; (* "Relaxed": The operation does not order memory. "Release": Performs a release operation on the affected memory locations, thus making regular memory writes visible to other threads through the variable to which it is applied. "Acquire": Performs an acquire operation on the affected memory locations, thus making regular memory writes in other threads released through the atomic variable to which it is applied, visible to the current thread. "AcquireRelease": The operation has both acquire and release semantics. "Sequential": The operation has both acquire and release semantics, and in addition, has sequentially-consistent operation ordering. *) CONST IsLockFree = Rep.IsLockFree; (* True if the operations are lock-free, false otherwise. *) PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); (* Atomically replace the value in "var" with "val". Memory is affected as per "order". The "order" shall be neither "Acquire" nor "AcquireRelease". *) PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; (* Atomically return the value in "var". Memory is affected as per "order". The "order" shall be neither "Release" nor "AcquireRelease". *) PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; (* Atomically replace the value in "var" with "val". Returns the value of "var" immediately before the effects. Memory is affected as per order. This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. *) PROCEDURE CompareSwap(VAR var, expected: T; desired: T; order := Order.Sequential): BOOLEAN; (* Atomically, compares the value in "var" for equality with that in "expected", and if true, replaces the value in "var" with "desired", and if false, updates the value in "expected" with the value in "var". Returns the result of the comparison. The "order" shall be neither "Release" nor "AcquireRelease". This is a read-modify-write operation and synchronizes with any evaluation that reads the updated value. The effect of the CompareSwap operation is: IF var = expected THEN var := desired ELSE expected := var; The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: expected := Atomic.Load(current); DO desired := function(expected); WHILE NOT Atomic.CompareSwap(current, expected, desired); *) PROCEDURE Fence(VAR var: T; order := Order.Sequential); (* Memory is affected as per "order". Synchronizes with any operation on the same variable. The "order" shall not be "Relaxed". *) PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; (* Atomically replace the value in "var" with the result of the operation applied to the value in "var" and the given operand. Memory is affected as per "order". These operations are read-modify-write operations and synchronize with any evaluation that reads the updated value. Returns the value of "var" immediately before the effects. For signed integral types, arithmetic is defined to use two's-complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior. *) END Atomic. From hosking at cs.purdue.edu Sun Dec 20 20:43:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 14:43:19 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <20091220035317.GA22518@topoi.pooq.com> References: <20091220035317.GA22518@topoi.pooq.com> Message-ID: On 19 Dec 2009, at 22:53, hendrik at topoi.pooq.com wrote: > It's not quite clear to me what these Orders mean. In particular, > I don't see a clear model for the interaction of 'visibility', 'memory > writes' and 'threads'. I can certainly find a ways to understand these > words, but I can't be sure I understand them the same way as they > are intended. > > Perhaps I lack context that is provided somewhere. These are as defined for the C++0x proposed standard. We should, of course, provide explicit description. Acquire/Release have the semantics you would expect for lock acquire and lock release: acquirers see operations performed by releasers. From rodney_bates at lcwb.coop Mon Dec 21 02:02:48 2009 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 20 Dec 2009 19:02:48 -0600 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> References: <4B2E5476.5000200@lcwb.coop> <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> Message-ID: <4B2EC938.5030703@lcwb.coop> Tony Hosking wrote: > Thanks for the typo fixes. > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > >> To be legal on ADDRESS, either another parallel interface or a set of parallel >> procedures would be needed. Or else, this interface would have to be known to >> the core language and allow predefined overloading, similar to builtin operators >> and functions. The syntax could still be that of an interface. I don't think >> any existing required interfaces do this now. > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: And would it be illegal to try to instantiate with any other type? I presume it would have to be a native word sized value for the implementation, and the Fetch operations would not have meaning for most other types. Also, would the corresponding MODULE and its instantiations not be written in M3, but just builtin to the compiler, like Word? > > GENERIC INTERFACE Atomic(Rep); > > TYPE T = Rep.T; > > TYPE > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > (* "Relaxed": The operation does not order memory. > > "Release": Performs a release operation on the affected memory locations, > thus making regular memory writes visible to other threads through the > variable to which it is applied. > > "Acquire": Performs an acquire operation on the affected memory > locations, thus making regular memory writes in other threads released > through the atomic variable to which it is applied, visible to the > current thread. > > "AcquireRelease": The operation has both acquire and release semantics. > > "Sequential": The operation has both acquire and release semantics, and > in addition, has sequentially-consistent operation ordering. *) > > CONST IsLockFree = Rep.IsLockFree; > (* True if the operations are lock-free, false otherwise. *) > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > (* Atomically replace the value in "var" with "val". Memory is affected as > per "order". The "order" shall be neither "Acquire" nor > "AcquireRelease". *) > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > (* Atomically return the value in "var". Memory is affected as per "order". > The "order" shall be neither "Release" nor "AcquireRelease". *) > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > (* Atomically replace the value in "var" with "val". Returns the value of > "var" immediately before the effects. Memory is affected as per order. > This is a read-modify-write operation and synchronizes with any > evaluation that reads the updated value. *) > > PROCEDURE CompareSwap(VAR var, expected: T; > desired: T; order := Order.Sequential): BOOLEAN; > (* Atomically, compares the value in "var" for equality with that in > "expected", and if true, replaces the value in "var" with "desired", and > if false, updates the value in "expected" with the value in "var". > Returns the result of the comparison. The "order" shall be neither > "Release" nor "AcquireRelease". This is a read-modify-write operation > and synchronizes with any evaluation that reads the updated value. The > effect of the CompareSwap operation is: > > IF var = expected THEN var := desired ELSE expected := var; > > The CompareSwap operation may fail spuriously, that is return false while > leaving the value in "expected" unchanged. A consequence of spurious > failure is that nearly all uses of CompareSwap will be in a loop: > > expected := Atomic.Load(current); > DO > desired := function(expected); > WHILE NOT Atomic.CompareSwap(current, expected, desired); > *) > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > (* Memory is affected as per "order". Synchronizes with any operation on > the same variable. The "order" shall not be "Relaxed". *) > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > (* Atomically replace the value in "var" with the result of the operation > applied to the value in "var" and the given operand. Memory is affected > as per "order". These operations are read-modify-write operations and > synchronize with any evaluation that reads the updated value. Returns > the value of "var" immediately before the effects. > > For signed integral types, arithmetic is defined to use two's-complement > representation. There are no undefined results. For address types, the > result may be an undefined address, but the operations otherwise have no > undefined behavior. *) > > END Atomic. > > From jay.krell at cornell.edu Mon Dec 21 02:37:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 01:37:29 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2EC938.5030703@lcwb.coop> References: , <4B2E5476.5000200@lcwb.coop>, <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, <4B2EC938.5030703@lcwb.coop> Message-ID: No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). Maybe not 8, but there readily available examples of the others. Search the web for: _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). - Jay > Date: Sun, 20 Dec 2009 19:02:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > Tony Hosking wrote: > > Thanks for the typo fixes. > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > >> procedures would be needed. Or else, this interface would have to be known to > >> the core language and allow predefined overloading, similar to builtin operators > >> and functions. The syntax could still be that of an interface. I don't think > >> any existing required interfaces do this now. > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. > > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? > > > > > GENERIC INTERFACE Atomic(Rep); > > > > TYPE T = Rep.T; > > > > TYPE > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > (* "Relaxed": The operation does not order memory. > > > > "Release": Performs a release operation on the affected memory locations, > > thus making regular memory writes visible to other threads through the > > variable to which it is applied. > > > > "Acquire": Performs an acquire operation on the affected memory > > locations, thus making regular memory writes in other threads released > > through the atomic variable to which it is applied, visible to the > > current thread. > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > "Sequential": The operation has both acquire and release semantics, and > > in addition, has sequentially-consistent operation ordering. *) > > > > CONST IsLockFree = Rep.IsLockFree; > > (* True if the operations are lock-free, false otherwise. *) > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > (* Atomically replace the value in "var" with "val". Memory is affected as > > per "order". The "order" shall be neither "Acquire" nor > > "AcquireRelease". *) > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > (* Atomically return the value in "var". Memory is affected as per "order". > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > (* Atomically replace the value in "var" with "val". Returns the value of > > "var" immediately before the effects. Memory is affected as per order. > > This is a read-modify-write operation and synchronizes with any > > evaluation that reads the updated value. *) > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > desired: T; order := Order.Sequential): BOOLEAN; > > (* Atomically, compares the value in "var" for equality with that in > > "expected", and if true, replaces the value in "var" with "desired", and > > if false, updates the value in "expected" with the value in "var". > > Returns the result of the comparison. The "order" shall be neither > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > and synchronizes with any evaluation that reads the updated value. The > > effect of the CompareSwap operation is: > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > The CompareSwap operation may fail spuriously, that is return false while > > leaving the value in "expected" unchanged. A consequence of spurious > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > expected := Atomic.Load(current); > > DO > > desired := function(expected); > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > *) > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > (* Memory is affected as per "order". Synchronizes with any operation on > > the same variable. The "order" shall not be "Relaxed". *) > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > (* Atomically replace the value in "var" with the result of the operation > > applied to the value in "var" and the given operand. Memory is affected > > as per "order". These operations are read-modify-write operations and > > synchronize with any evaluation that reads the updated value. Returns > > the value of "var" immediately before the effects. > > > > For signed integral types, arithmetic is defined to use two's-complement > > representation. There are no undefined results. For address types, the > > result may be an undefined address, but the operations otherwise have no > > undefined behavior. *) > > > > END Atomic. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 21 03:23:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 21:23:37 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <4B2EC938.5030703@lcwb.coop> References: <4B2E5476.5000200@lcwb.coop> <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu> <4B2EC938.5030703@lcwb.coop> Message-ID: <8B7D053E-444A-490B-AF3D-34EA2776B40C@cs.purdue.edu> On 20 Dec 2009, at 20:02, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> Thanks for the typo fixes. >> On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: >>> To be legal on ADDRESS, either another parallel interface or a set of parallel >>> procedures would be needed. Or else, this interface would have to be known to >>> the core language and allow predefined overloading, similar to builtin operators >>> and functions. The syntax could still be that of an interface. I don't think >>> any existing required interfaces do this now. >> Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. It's an interesting question if we could instantiate with other types. For now, I am assuming not. > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? Yes, that would be the goal, though for now we will not rely on compiler support because gcc doesn't yet have everything we need. (It may have some in the existing sync builtins, but they have undefined memory ordering semantics, and probably are only meaningful on Intel x86/x86_64). > >> GENERIC INTERFACE Atomic(Rep); >> TYPE T = Rep.T; >> TYPE >> Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; >> (* "Relaxed": The operation does not order memory. >> "Release": Performs a release operation on the affected memory locations, >> thus making regular memory writes visible to other threads through the >> variable to which it is applied. >> "Acquire": Performs an acquire operation on the affected memory >> locations, thus making regular memory writes in other threads released >> through the atomic variable to which it is applied, visible to the >> current thread. >> "AcquireRelease": The operation has both acquire and release semantics. >> "Sequential": The operation has both acquire and release semantics, and >> in addition, has sequentially-consistent operation ordering. *) >> CONST IsLockFree = Rep.IsLockFree; >> (* True if the operations are lock-free, false otherwise. *) >> PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); >> (* Atomically replace the value in "var" with "val". Memory is affected as >> per "order". The "order" shall be neither "Acquire" nor >> "AcquireRelease". *) >> PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; >> (* Atomically return the value in "var". Memory is affected as per "order". >> The "order" shall be neither "Release" nor "AcquireRelease". *) >> PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; >> (* Atomically replace the value in "var" with "val". Returns the value of >> "var" immediately before the effects. Memory is affected as per order. >> This is a read-modify-write operation and synchronizes with any >> evaluation that reads the updated value. *) >> PROCEDURE CompareSwap(VAR var, expected: T; >> desired: T; order := Order.Sequential): BOOLEAN; >> (* Atomically, compares the value in "var" for equality with that in >> "expected", and if true, replaces the value in "var" with "desired", and >> if false, updates the value in "expected" with the value in "var". >> Returns the result of the comparison. The "order" shall be neither >> "Release" nor "AcquireRelease". This is a read-modify-write operation >> and synchronizes with any evaluation that reads the updated value. The >> effect of the CompareSwap operation is: >> IF var = expected THEN var := desired ELSE expected := var; >> The CompareSwap operation may fail spuriously, that is return false while >> leaving the value in "expected" unchanged. A consequence of spurious >> failure is that nearly all uses of CompareSwap will be in a loop: >> expected := Atomic.Load(current); >> DO >> desired := function(expected); >> WHILE NOT Atomic.CompareSwap(current, expected, desired); >> *) >> PROCEDURE Fence(VAR var: T; order := Order.Sequential); >> (* Memory is affected as per "order". Synchronizes with any operation on >> the same variable. The "order" shall not be "Relaxed". *) >> PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; >> PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; >> PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; >> PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; >> PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; >> (* Atomically replace the value in "var" with the result of the operation >> applied to the value in "var" and the given operand. Memory is affected >> as per "order". These operations are read-modify-write operations and >> synchronize with any evaluation that reads the updated value. Returns >> the value of "var" immediately before the effects. >> For signed integral types, arithmetic is defined to use two's-complement >> representation. There are no undefined results. For address types, the >> result may be an undefined address, but the operations otherwise have no >> undefined behavior. *) >> END Atomic. From hosking at cs.purdue.edu Mon Dec 21 03:25:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Dec 2009 21:25:30 -0500 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: References: , <4B2E5476.5000200@lcwb.coop>, <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, <4B2EC938.5030703@lcwb.coop> Message-ID: <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> If we build on the libatomic_ops support then some types might end up with (slow) implementation using locks. On 20 Dec 2009, at 20:37, Jay K wrote: > No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). > Maybe not 8, but there readily available examples of the others. > > Search the web for: > _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx > _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx > _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx > > Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). > > - Jay > > > > Date: Sun, 20 Dec 2009 19:02:48 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > > > > > Tony Hosking wrote: > > > Thanks for the typo fixes. > > > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > > >> procedures would be needed. Or else, this interface would have to be known to > > >> the core language and allow predefined overloading, similar to builtin operators > > >> and functions. The syntax could still be that of an interface. I don't think > > >> any existing required interfaces do this now. > > > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > > > And would it be illegal to try to instantiate with any other type? I presume it would > > have to be a native word sized value for the implementation, and the Fetch operations > > would not have meaning for most other types. > > > > Also, would the corresponding MODULE and its instantiations not be written in M3, > > but just builtin to the compiler, like Word? > > > > > > > > GENERIC INTERFACE Atomic(Rep); > > > > > > TYPE T = Rep.T; > > > > > > TYPE > > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > > (* "Relaxed": The operation does not order memory. > > > > > > "Release": Performs a release operation on the affected memory locations, > > > thus making regular memory writes visible to other threads through the > > > variable to which it is applied. > > > > > > "Acquire": Performs an acquire operation on the affected memory > > > locations, thus making regular memory writes in other threads released > > > through the atomic variable to which it is applied, visible to the > > > current thread. > > > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > > > "Sequential": The operation has both acquire and release semantics, and > > > in addition, has sequentially-consistent operation ordering. *) > > > > > > CONST IsLockFree = Rep.IsLockFree; > > > (* True if the operations are lock-free, false otherwise. *) > > > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > > (* Atomically replace the value in "var" with "val". Memory is affected as > > > per "order". The "order" shall be neither "Acquire" nor > > > "AcquireRelease". *) > > > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > > (* Atomically return the value in "var". Memory is affected as per "order". > > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > > (* Atomically replace the value in "var" with "val". Returns the value of > > > "var" immediately before the effects. Memory is affected as per order. > > > This is a read-modify-write operation and synchronizes with any > > > evaluation that reads the updated value. *) > > > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > > desired: T; order := Order.Sequential): BOOLEAN; > > > (* Atomically, compares the value in "var" for equality with that in > > > "expected", and if true, replaces the value in "var" with "desired", and > > > if false, updates the value in "expected" with the value in "var". > > > Returns the result of the comparison. The "order" shall be neither > > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > > and synchronizes with any evaluation that reads the updated value. The > > > effect of the CompareSwap operation is: > > > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > > > The CompareSwap operation may fail spuriously, that is return false while > > > leaving the value in "expected" unchanged. A consequence of spurious > > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > > > expected := Atomic.Load(current); > > > DO > > > desired := function(expected); > > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > > *) > > > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > > (* Memory is affected as per "order". Synchronizes with any operation on > > > the same variable. The "order" shall not be "Relaxed". *) > > > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > > (* Atomically replace the value in "var" with the result of the operation > > > applied to the value in "var" and the given operand. Memory is affected > > > as per "order". These operations are read-modify-write operations and > > > synchronize with any evaluation that reads the updated value. Returns > > > the value of "var" immediately before the effects. > > > > > > For signed integral types, arithmetic is defined to use two's-complement > > > representation. There are no undefined results. For address types, the > > > result may be an undefined address, but the operations otherwise have no > > > undefined behavior. *) > > > > > > END Atomic. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 05:24:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 04:24:13 +0000 Subject: [M3devel] Proposed Atomic Word.T interfaces. In-Reply-To: <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> References: , , <4B2E5476.5000200@lcwb.coop>, , <534D85FF-03FC-4666-932E-2BABE1795D14@cs.purdue.edu>, , <4B2EC938.5030703@lcwb.coop>, , <5CD2867D-8C62-4938-80EC-E975920A234C@cs.purdue.edu> Message-ID: Many operations on non-words sizes are perfectly good, no locks, on x86, AMD64, IA64. _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx It's a processor thing, not an OS thing, so whatever Windows supports is trivial on any other x86/AMD64/IA64 system. - Jay From: hosking at cs.purdue.edu Date: Sun, 20 Dec 2009 21:25:30 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. If we build on the libatomic_ops support then some types might end up with (slow) implementation using locks. On 20 Dec 2009, at 20:37, Jay K wrote:No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems). Maybe not 8, but there readily available examples of the others. Search the web for: _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old"). - Jay > Date: Sun, 20 Dec 2009 19:02:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Proposed Atomic Word.T interfaces. > > > > Tony Hosking wrote: > > Thanks for the typo fixes. > > > > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote: > > > >> To be legal on ADDRESS, either another parallel interface or a set of parallel > >> procedures would be needed. Or else, this interface would have to be known to > >> the core language and allow predefined overloading, similar to builtin operators > >> and functions. The syntax could still be that of an interface. I don't think > >> any existing required interfaces do this now. > > > > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T: > > And would it be illegal to try to instantiate with any other type? I presume it would > have to be a native word sized value for the implementation, and the Fetch operations > would not have meaning for most other types. > > Also, would the corresponding MODULE and its instantiations not be written in M3, > but just builtin to the compiler, like Word? > > > > > GENERIC INTERFACE Atomic(Rep); > > > > TYPE T = Rep.T; > > > > TYPE > > Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential }; > > (* "Relaxed": The operation does not order memory. > > > > "Release": Performs a release operation on the affected memory locations, > > thus making regular memory writes visible to other threads through the > > variable to which it is applied. > > > > "Acquire": Performs an acquire operation on the affected memory > > locations, thus making regular memory writes in other threads released > > through the atomic variable to which it is applied, visible to the > > current thread. > > > > "AcquireRelease": The operation has both acquire and release semantics. > > > > "Sequential": The operation has both acquire and release semantics, and > > in addition, has sequentially-consistent operation ordering. *) > > > > CONST IsLockFree = Rep.IsLockFree; > > (* True if the operations are lock-free, false otherwise. *) > > > > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential); > > (* Atomically replace the value in "var" with "val". Memory is affected as > > per "order". The "order" shall be neither "Acquire" nor > > "AcquireRelease". *) > > > > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T; > > (* Atomically return the value in "var". Memory is affected as per "order". > > The "order" shall be neither "Release" nor "AcquireRelease". *) > > > > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T; > > (* Atomically replace the value in "var" with "val". Returns the value of > > "var" immediately before the effects. Memory is affected as per order. > > This is a read-modify-write operation and synchronizes with any > > evaluation that reads the updated value. *) > > > > PROCEDURE CompareSwap(VAR var, expected: T; > > desired: T; order := Order.Sequential): BOOLEAN; > > (* Atomically, compares the value in "var" for equality with that in > > "expected", and if true, replaces the value in "var" with "desired", and > > if false, updates the value in "expected" with the value in "var". > > Returns the result of the comparison. The "order" shall be neither > > "Release" nor "AcquireRelease". This is a read-modify-write operation > > and synchronizes with any evaluation that reads the updated value. The > > effect of the CompareSwap operation is: > > > > IF var = expected THEN var := desired ELSE expected := var; > > > > The CompareSwap operation may fail spuriously, that is return false while > > leaving the value in "expected" unchanged. A consequence of spurious > > failure is that nearly all uses of CompareSwap will be in a loop: > > > > expected := Atomic.Load(current); > > DO > > desired := function(expected); > > WHILE NOT Atomic.CompareSwap(current, expected, desired); > > *) > > > > PROCEDURE Fence(VAR var: T; order := Order.Sequential); > > (* Memory is affected as per "order". Synchronizes with any operation on > > the same variable. The "order" shall not be "Relaxed". *) > > > > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T; > > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T; > > PROCEDURE FetchOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchXOr (VAR var: T; mask: T; order := Sequential): T; > > PROCEDURE FetchAnd (VAR var: T; mask: T; order := Sequential): T; > > (* Atomically replace the value in "var" with the result of the operation > > applied to the value in "var" and the given operand. Memory is affected > > as per "order". These operations are read-modify-write operations and > > synchronize with any evaluation that reads the updated value. Returns > > the value of "var" immediately before the effects. > > > > For signed integral types, arithmetic is defined to use two's-complement > > representation. There are no undefined results. For address types, the > > result may be an undefined address, but the operations otherwise have no > > undefined behavior. *) > > > > END Atomic. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 21 10:04:36 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Dec 2009 04:04:36 -0500 Subject: [M3devel] build problems on Windows 2000 Message-ID: <4B2EC19B020000D700069A01@scires.com> I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 07:27:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: <4B2EC19B020000D700069A01@scires.com> References: <4B2EC19B020000D700069A01@scires.com> Message-ID: windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 21 07:38:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 06:38:33 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: References: <4B2EC19B020000D700069A01@scires.com>, Message-ID: windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Dec 21 21:57:09 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Dec 2009 15:57:09 -0500 Subject: [M3devel] build problems on Windows 2000 Message-ID: <4B2F67D1020000D700069AC6@scires.com> Jay et al: Oops, sorry. I forgot about the SDK requirements for developing Win32 apps. BTW, seems that after Microsoft came out with the 2008 edition of Visual Studio Express, they have dropped the 2005 editions. The 2008 edition doesn't support Windows 2000, so getting the 2005 edition is a bit tricky. I managed to find a C++ 2005 edition after much searching on the web. Likewise, all the Microsoft links for the SDK now point to the newer editions which aren't compatible with Windows 2000. I've managed to find a link to the SDK and am installing it now. Thanks for your help, but we may have trouble supporting Windows 2000 in the future if folks can't get the Microsoft tools for this platform. I wonder if we would be allowed to host old versions of the tools? Regards, Randy >>> Jay K 12/21/09 1:47 AM >>> windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay
From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 .ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Verdana;} windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay
Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 22 00:25:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Dec 2009 23:25:17 +0000 Subject: [M3devel] build problems on Windows 2000 In-Reply-To: <4B2F67D1020000D700069AC6@scires.com> References: <4B2F67D1020000D700069AC6@scires.com> Message-ID: Probably we cannot host the old tools. There are independent windows.h, in fact I checked them in, though I did so with a different and now abandoned goal in mind. See m3-win\w32api. We could go that route if people really want. Really I think if people want to support Windows 2000, they should have acquired compiler/linker ahead of time, or do something else like use Cygwin or DigitalMars or such. You can also find everything on eBay. The non-Express tools always come with windows.h, etc. - Jay Date: Mon, 21 Dec 2009 15:57:09 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] build problems on Windows 2000 Jay et al: Oops, sorry. I forgot about the SDK requirements for developing Win32 apps. BTW, seems that after Microsoft came out with the 2008 edition of Visual Studio Express, they have dropped the 2005 editions. The 2008 edition doesn't support Windows 2000, so getting the 2005 edition is a bit tricky. I managed to find a C++ 2005 edition after much searching on the web. Likewise, all the Microsoft links for the SDK now point to the newer editions which aren't compatible with Windows 2000. I've managed to find a link to the SDK and am installing it now. Thanks for your help, but we may have trouble supporting Windows 2000 in the future if folks can't get the Microsoft tools for this platform. I wonder if we would be allowed to host old versions of the tools? Regards, Randy >>> Jay K 12/21/09 1:47 AM >>> windows.h really is a basic requirement. search for "visual C++ 2005 express sdk": http://msdn.microsoft.com/en-us/visualc/aa336415.aspx http://msdn.microsoft.com/en-us/library/ms235626%28VS.80%29.aspx http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en etc. - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Date: Mon, 21 Dec 2009 06:27:28 +0000 Subject: Re: [M3devel] build problems on Windows 2000 windows.h really is a basic requirement. www.microsoft.com/sdk => http://msdn.microsoft.com/en-us/windows/bb980924.aspx - Jay Date: Mon, 21 Dec 2009 04:04:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] build problems on Windows 2000 I got my hands on a Windows 2000 computer and decided to try and build cm3 on it. I get a build failure on m3-libs\m3core. Seems I am missing a file "Windows.h" This computer has Windows 2000 Professional SP4 and Microsoft Visual C++ Express 2005 installed. Any ideas where I should get the Windows.h file from? --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 new source -> compiling RTHeap.i3 new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 new source -> compiling RTDebug.m3 new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 new source -> compiling RTProcedure.m3 new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 new source -> compiling RTType.m3 new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 new source -> compiling RTTypeMap.m3 new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 new source -> compiling Cstdint.i3 new source -> compiling WinBaseTypes.i3 new source -> compiling WinNT.i3 new source -> compiling WinBase.i3 new source -> compiling WinDef.i3 new source -> compiling RTArgs.m3 new source -> compiling WinCon.i3 new source -> compiling RTMachInfo.i3 new source -> compiling RTOS.m3 new source -> compiling RTPerfTool.m3 new source -> compiling ThreadContext.i3 new source -> compiling RTSignal.m3 new source -> compiling RTMachInfo.m3 new source -> compiling Csetjmp.i3 new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 new source -> compiling ThreadF.i3 new source -> compiling ThreadDebug.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadWin32.i3 new source -> compiling WinGDI.i3 new source -> compiling ThreadWin32.m3 new source -> compiling WinDef.m3 new source -> compiling WinNT.m3 new source -> compiling WinError.i3 new source -> compiling WinGDI.m3 new source -> compiling WinIoctl.i3 new source -> compiling WinIoctl.m3 new source -> compiling WinNetwk.i3 new source -> compiling WinNLS.i3 new source -> compiling WinReg.i3 new source -> compiling WinReg.m3 new source -> compiling WinSock.i3 new source -> compiling WinSock.m3 new source -> compiling WinUser.i3 new source -> compiling WinUser.m3 new source -> compiling WinVer.i3 new source -> compiling WinVer.m3 new source -> compiling NB30.i3 new source -> compiling NB30.m3 new source -> compiling CDErr.i3 new source -> compiling CommDlg.i3 new source -> compiling TlHelp32.i3 new source -> compiling WinMidi.i3 new source -> compiling WinCommCtrl.i3 new source -> compiling WinTabCon.i3 new source -> compiling WinImageList.i3 new source -> compiling WinTabCon.m3 new source -> compiling WinListView.i3 new source -> compiling Text8.i3 new source -> compiling WinListView.m3 new source -> compiling WinImageList.m3 new source -> compiling Unix.i3 new source -> compiling Uuio.i3 new source -> compiling Cerrno.i3 new source -> compiling Text8CString.i3 new source -> compiling M3toC.m3 new source -> compiling Cstdio.i3 new source -> compiling Csignal.i3 new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 new source -> compiling LongFloat.m3 new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 new source -> compiling TickPortable.m3 new source -> compiling TimeWin32.i3 new source -> compiling Time.m3 new source -> compiling TimeWin32.m3 new source -> compiling DateWin32.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 new source -> compiling Convert.m3 new source -> compiling String8.i3 new source -> compiling String8.m3 new source -> compiling String16.i3 new source -> compiling String16.m3 new source -> compiling Text16.i3 new source -> compiling Text.m3 new source -> compiling TextClass.m3 new source -> compiling TextLiteral.m3 new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 new source -> compiling Text8Short.m3 new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 new source -> compiling Text16Short.m3 new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 new source -> compiling TextCat.m3 new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 new source -> compiling Poly.m3 new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 new source -> compiling Long.m3 new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c new source -> compiling RTLinkerC.c new source -> compiling RTMiscC.c new source -> compiling RTOSc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\runtime\\W IN32\\RTOSc.c RTOSc.c ..\\src\\runtime\\WIN32\\RTOSc.c(21) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\runtime\WIN32\RTOSc.c new source -> compiling RTStackC.c new source -> compiling ThreadDebug.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\Co mmon\\ThreadDebug.c ThreadDebug.c ..\\src\\thread\\Common\\ThreadDebug.c(24) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\Common\ThreadDebug.c new source -> compiling ThreadWin32C.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\thread\\WI N32\\ThreadWin32C.c ThreadWin32C.c ..\\src\\thread\\WIN32\\ThreadWin32C.c(16) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\thread\WIN32\ThreadWin32C.c new source -> compiling WinNTc.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinNTc.c WinNTc.c ..\\src\\win32\\WinNTc.c(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinNTc.c new source -> compiling WinUserC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\win32\\WinUserC.c WinUserC.c ..\\src\\win32\\WinUserC.c(5) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\win32\WinUserC.c new source -> compiling CstdlibC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdlibC.c CstdlibC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdlibC.c new source -> compiling CerrnoC.c new source -> compiling CstringC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstringC.c CstringC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h':No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstringC.c new source -> compiling CstdioC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CstdioC.c CstdioC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CstdioC.c new source -> compiling CsignalC.c cl.exe -nologo -Z7 -DWIN32 -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/WIN32 -I../src/win32 -I../src/C/Common -MD -Oi -c ..\\src\\C\\Common\\CsignalC.c CsignalC.c ../src\m3core.h(85) : fatal error C1083: Cannot open include file: 'winsock.h': No such file or directory compile_c => 2 C compiler failed compiling: ..\src\C\Common\CsignalC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "m3core.lib" Fatal Error: package build failed Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 22 18:02:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Dec 2009 17:02:23 +0000 Subject: [M3devel] head vs. release threads? Message-ID: Tony can you look at head vs. release m3core/threads and such and decide if you want all of head in release? The changes I know about are - handling low resources in pthread, the can of worms I keep prying on :) - something in user threads, I didn't read enough to understand - other stuff in user threads -- sigaltstack for openbsd I'll get Win32 -- eliminating an extra acquire/release in the InnerWait loop. Beyond that the things to consider are - assertions and dependency on time_t definition and such - keying off of processor or "os" (linux,openbsd, etc.) instead of full platform (amd64_linux, i386_openbsd, etc.) - Uconstants.c is in different order and impossible to read diff; I need to sort it or something Just copying all of head m3core to release is probably fine though I try to be a little arbitrarily slow/methodical as a substitute for being conservative, sometimes, something illogical like that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 22 18:22:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Dec 2009 12:22:04 -0500 Subject: [M3devel] head vs. release threads? In-Reply-To: References: Message-ID: <2A82B86D-732B-45AA-9E93-A142C87CFE2D@cs.purdue.edu> I thought we were aiming for stability in the release branch, rather than new functionality. My preference is to not change the release branch too much so long as fundamental functionality is there and correct... On 22 Dec 2009, at 12:02, Jay K wrote: > Tony can you look at head vs. release m3core/threads and such and decide if you want all of head in release? > The changes I know about are > - handling low resources in pthread, the can of worms I keep prying on :) > - something in user threads, I didn't read enough to understand > - other stuff in user threads -- sigaltstack for openbsd > > I'll get Win32 -- eliminating an extra acquire/release in the InnerWait loop. > > > Beyond that the things to consider are > - assertions and dependency on time_t definition and such > - keying off of processor or "os" (linux,openbsd, etc.) instead of full platform (amd64_linux, i386_openbsd, etc.) > - Uconstants.c is in different order and impossible to read diff; I need to sort it or something > > > Just copying all of head m3core to release is probably fine though I try to be a little arbitrarily > slow/methodical as a substitute for being conservative, sometimes, something illogical like that. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Dec 23 04:42:24 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Dec 2009 03:42:24 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20091221150040.B051E2474001@birch.elegosoft.com> Message-ID: <770199.13762.qm@web23608.mail.ird.yahoo.com> Hi all: forgive my ignorance about the actual changes going on below copied M3commit message of Monday, December 21, 16:00:40 but what is this to have gcc code inside the compiler libs, I recommend to check the strict rules about this before performing such changes, Is there any problem getting gcc code inside the runtime libraries, even if this only used in level C code, this gets more C dependences in non-M3 code we are not able to guarantee, better UNSAFE than totally unmarked unsafe again. If this is not the case, and just a piece of m3cc related code I don't disqualify it yet. Thanks in advance --- El lun, 21/12/09, Jay Krell escribi?: > De: Jay Krell > Asunto: [M3commit] CVS Update: cm3 > Para: m3commit at elegosoft.com > Fecha: lunes, 21 de diciembre, 2009 11:00 > CVSROOT: /usr/cvs > Changes by: > jkrell at birch. 09/12/21 16:00:40 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/libgcc/: > libgcc.c > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > cm3/m3-libs/m3core/src/runtime/DS3100/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/POSIX/: > RTOSbrk.c RTOSmmap.c > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/SOLsun/: > RTStackC.c > cm3/m3-libs/m3core/src/runtime/WIN32/: > RTOSc.c > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > Log message: > add mising #ifdef cplusplus extern "C" { > } > > From dabenavidesd at yahoo.es Wed Dec 23 05:47:27 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Dec 2009 04:47:27 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <770199.13762.qm@web23608.mail.ird.yahoo.com> Message-ID: <468779.46976.qm@web23608.mail.ird.yahoo.com> Hi again: I recall to have said about a virtualization infrastructure future framework for CM3 reusing existing work made by DEC and SPIN, if we manage to get the system running as a separate process in a given processor we will be definitely getting source code level compability between UNIX implementations by means of a huge historical system like DEC UNIX and a good balance on terms of security in the Modula-3 runtime protection of foreign code. If there is no case of having user level DEC Unix server running in a host processor we can still emulate like they did and/or have a M3 Unix server inside the kernel like they planed to do. In perspective SPINE (spin development) developed a embedded system in NT kernel without touching host system processor but the actual network interface card internal processor featuring several M3 applications running on it. This would be a potential place for higher optimization in the CM3 system as we wouldn't have the usual architecture M3 guest-per system but a M3 host per system given the opportunities for it Hope this helps in something, thanks in advance --- El mar, 22/12/09, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] [M3commit] CVS Update: cm3 > Para: m3commit at elegosoft.com, jkrell at elego.de > CC: m3devel at elegosoft.com > Fecha: martes, 22 de diciembre, 2009 22:42 > Hi all: > forgive my ignorance about the actual changes going on > below copied M3commit message of Monday, December 21, > 16:00:40 but what is this to have gcc code inside the > compiler libs, I recommend to check the strict rules about > this before performing such changes, Is there any problem > getting gcc code inside the runtime libraries, even if this > only used in level C code, this gets more C dependences in > non-M3 code we are not able to guarantee, better UNSAFE than > totally unmarked unsafe again. If this is not the case, and > just a piece of m3cc related code I don't disqualify it > yet. > Thanks in advance > > --- El lun, 21/12/09, Jay Krell > escribi?: > > > De: Jay Krell > > Asunto: [M3commit] CVS Update: cm3 > > Para: m3commit at elegosoft.com > > Fecha: lunes, 21 de diciembre, 2009 11:00 > > CVSROOT: /usr/cvs > > Changes by: > > jkrell at birch. 09/12/21 16:00:40 > > > > Modified files: > > > cm3/m3-libs/m3core/src/Csupport/libgcc/: > > libgcc.c > > > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > > > > cm3/m3-libs/m3core/src/runtime/DS3100/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/POSIX/: > > RTOSbrk.c RTOSmmap.c > > > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/SOLsun/: > > RTStackC.c > > > cm3/m3-libs/m3core/src/runtime/WIN32/: > > RTOSc.c > > > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > > > Log message: > > add mising #ifdef cplusplus > extern "C" { > > } > > > > > > > > From jay.krell at cornell.edu Wed Dec 23 11:15:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Dec 2009 10:15:51 +0000 Subject: [M3devel] libgcc.c In-Reply-To: <770199.13762.qm@web23608.mail.ird.yahoo.com> References: <20091221150040.B051E2474001@birch.elegosoft.com>, <770199.13762.qm@web23608.mail.ird.yahoo.com> Message-ID: Daniel, please look at the file. If you write the following sorts of Modula-3 code: PROCEDURE Add64(a,b: LONGINT):LONGINT= RETURN a + b; END Add64; PROCEDURE Mult64(a,b: LONGINT):LONGINT= RETURN a * b; END Mult64; PROCEDURE Div64(a,b: LONGINT):LONGINT= RETURN a / b; END Div64; Or the following sorts of C code: long long add64(long long a, long long b) { return a + b; } long long mult64(long long a, long long b) { return a * b; } long long div64(long long a, long long b) { return a / b; } fanything that does these operations, not just functions that /only/ do them, on some architectures (esp. 32 bit ones), the backend (or C compiler) will emit function calls. If gcc is the compiler/linker, it always throws libgcc.a or such, and the functions are resolved. Any C code has this property. libgcc.a is liberally licensed. Again, any C code possibly links in this code. On systems where m3cg is the backend but gcc is not the compiler/linker, e.g. SOLsun, you don't get libgcc.a, but you still get these function calls. Therefore, on a platform like SOLsun, the solution is write functions very much like the above, but with names that match what the backend emits. In fact, what might occur is Sun CC emits function calls to functions with yet other names. That's awfully inefficient (two function calls to do a multiply) but it does work. It might be good if we could teach m3cg about the function names used by other compilers/runtimes. But it's also probably only a problem on 32bit platforms and they are the past. Apparently there is some doubt as to if these functions are needed on 64bit platforms, as you can see in the comments (at least in the original). - Jay > Date: Wed, 23 Dec 2009 03:42:24 +0000 > From: dabenavidesd at yahoo.es > To: m3commit at elegosoft.com; jkrell at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hi all: > forgive my ignorance about the actual changes going on below copied M3commit message of Monday, December 21, 16:00:40 but what is this to have gcc code inside the compiler libs, I recommend to check the strict rules about this before performing such changes, Is there any problem getting gcc code inside the runtime libraries, even if this only used in level C code, this gets more C dependences in non-M3 code we are not able to guarantee, better UNSAFE than totally unmarked unsafe again. If this is not the case, and just a piece of m3cc related code I don't disqualify it yet. > Thanks in advance > > --- El lun, 21/12/09, Jay Krell escribi?: > > > De: Jay Krell > > Asunto: [M3commit] CVS Update: cm3 > > Para: m3commit at elegosoft.com > > Fecha: lunes, 21 de diciembre, 2009 11:00 > > CVSROOT: /usr/cvs > > Changes by: > > jkrell at birch. 09/12/21 16:00:40 > > > > Modified files: > > cm3/m3-libs/m3core/src/Csupport/libgcc/: > > libgcc.c > > > > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c > > cm3/m3-libs/m3core/src/runtime/DS3100/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/POSIX/: > > RTOSbrk.c RTOSmmap.c > > cm3/m3-libs/m3core/src/runtime/SOLgnu/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/SOLsun/: > > RTStackC.c > > cm3/m3-libs/m3core/src/runtime/WIN32/: > > RTOSc.c > > > > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > > > > Log message: > > add mising #ifdef cplusplus extern "C" { > > } > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 23 23:50:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Dec 2009 22:50:52 +0000 Subject: [M3devel] Atomic In-Reply-To: <20091223223914.03AD02474001@birch.elegosoft.com> References: <20091223223914.03AD02474001@birch.elegosoft.com> Message-ID: Can/should we have something like AtomicWordPair or AtomicWordArray2? TYPE WordPair = RECORD a,b: Word.T END; or TYPE WordArray2 = ARRAY[0..1] of Word.T; Because modern x86 and very modern AMD64 can support Atomic.CompareExchange(WordPair). I kind of think there should also be AtomicShort or AtomicInt16 for completeness. I realize WideChar covers it, but then, char==boolean also, right? I forget what BYTESIZE(BOOLEAN) is actually. The obvious candidates are 1 and BYTESIZE(INTEGER) and 4 ("int"). For that matter..there aren't clearly 32bit operations on 64bit platforms (depending upon boolean). Which all goes to my earlier repeated point.. Atomic8, Atomic16, Atomic32, Atomic64, Atomic128, AtomicInt = Atomic32 or Atomic64, AtomicLongInt = Atomic64, AtomicWideChar = Atomic16, AtomicBool = Atomic8 or AtomicInt... - Jay > Date: Wed, 23 Dec 2009 23:39:13 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 09/12/23 23:39:13 > > Added files: > cm3/m3-libs/m3core/src/atomic/: Atomic.ig AtomicAddress.i3 > AtomicBoolean.i3 AtomicChar.i3 > AtomicInteger.i3 > AtomicLongint.i3 AtomicRefany.i3 > AtomicWideChar.i3 AtomicWord.i3 > > Log message: > Working up the Atomic interface. Comments welcome. > No implementation yet, so don't try using these... you'll get linkage errors. > But they do compile. ;-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 24 01:12:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Dec 2009 19:12:02 -0500 Subject: [M3devel] Atomic In-Reply-To: References: <20091223223914.03AD02474001@birch.elegosoft.com> Message-ID: Jay, this is Modula-3 not C. We support atomic on the Modula-3 primitive types. All of the sizes you ask for are supported. Even DCAS for 64-bit on 32-bit I Sent from my iPhone On Dec 23, 2009, at 5:50 PM, Jay K wrote: > Can/should we have something like AtomicWordPair or AtomicWordArray2? > > TYPE WordPair = RECORD a,b: Word.T END; > or TYPE WordArray2 = ARRAY[0..1] of Word.T; > > Because modern x86 and very modern AMD64 can support > Atomic.CompareExchange(WordPair). > > I kind of think there should also be AtomicShort or AtomicInt16 for > completeness. > I realize WideChar covers it, but then, char==boolean also, right? > I forget what BYTESIZE(BOOLEAN) is actually. The obvious candidates > are 1 and BYTESIZE(INTEGER) and 4 ("int"). > > For that matter..there aren't clearly 32bit operations on 64bit > platforms (depending upon boolean). > Which all goes to my earlier repeated point.. Atomic8, Atomic16, > Atomic32, Atomic64, Atomic128, AtomicInt = Atomic32 or Atomic64, > AtomicLongInt = Atomic64, AtomicWideChar = Atomic16, AtomicBool = > Atomic8 or AtomicInt... > > - Jay > > > > Date: Wed, 23 Dec 2009 23:39:13 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/12/23 23:39:13 > > > > Added files: > > cm3/m3-libs/m3core/src/atomic/: Atomic.ig AtomicAddress.i3 > > AtomicBoolean.i3 AtomicChar.i3 > > AtomicInteger.i3 > > AtomicLongint.i3 AtomicRefany.i3 > > AtomicWideChar.i3 AtomicWord.i3 > > > > Log message: > > Working up the Atomic interface. Comments welcome. > > No implementation yet, so don't try using these... you'll get > linkage errors. > > But they do compile. ;-) > > From jay.krell at cornell.edu Thu Dec 24 16:17:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Dec 2009 15:17:54 +0000 Subject: [M3devel] external two level names? Message-ID: Should we have a form of <*external*> that assumes two level names insead of one level names? This would be useful I believe for an initial implementation of Atomic. I don't see how to implement Atomic otherwise, well, other than a lame: Atomic.mg: if BYTESIZE(T) == 4 blah elsif BYTESIZE(T) == 8 blah which I guess is ok, or a switch. It'd also be very useful in the existing code base. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 24 16:35:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Dec 2009 10:35:07 -0500 Subject: [M3devel] external two level names? In-Reply-To: References: Message-ID: <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> I don't understand the question. I have a pretty good idea how to implement atomic without that. On 24 Dec 2009, at 10:17, Jay K wrote: > Should we have a form of <*external*> that assumes two level > names insead of one level names? > > This would be useful I believe for an initial implementation of Atomic. > I don't see how to implement Atomic otherwise, well, other than a lame: > > Atomic.mg: > if BYTESIZE(T) == 4 > blah > elsif BYTESIZE(T) == 8 > blah > > which I guess is ok, or a switch. > > It'd also be very useful in the existing code base. > > - Jay > > > > > From jay.krell at cornell.edu Thu Dec 24 20:57:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Dec 2009 19:57:32 +0000 Subject: [M3devel] external two level names? In-Reply-To: <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> References: , <760BACE3-B019-43AE-A63C-F745EC57A4FE@cs.purdue.edu> Message-ID: Imagine it is implemented by actual functions and not by the compiler? Like: interface AtomicInteger; <*external AtomicInteger__FetchAdd*> PROCEDURE FetchAdd(...) <*external AtomicInteger__CompareAndSwap*> PROCEDURE CompareAndSwap(...) interface AtomicWchar; <*external AtomicWchar__FetchAdd*> PROCEDURE FetchAdd(...) <*external AtomicWchar__CompareAndSwap*> PROCEDURE CompareAndSwap(...) all by instantiating Atomic.ig. <*external*> generic interface Atomic; PROCEDURE FetchAdd(...) PROCEDURE CompareAndSwap(...) Actually I just realize the language elements are maybe there. There is already a notion of an external interface. But as I understand, in the above, every instantiation would have the same external names. How about we change generic external interfaces to be "two level"? There are situations where the existing behavior would suffice that this would break, like if you had a generic that only operated on pointers but instantiated it for multiple pointer types, in that case using the same external name for every function would be ok. I've never seen an external interface until recently when I made some, let alone a generic external interface so this probably breaks nothing. Even so, we could add syntax to external. That is, this is useful for non-generic too. Interface unix <*external unix__sleep*> PROCEDURE sleep... <*external unix__open*> PROCEDURE open... vs. <*external twolevel*> interface unix; PROCEDURE sleep... PROCEDURE open... Granted, maybe something like: AtomicImpl.i3 <* external atomic__increment8 *> procedure increment8... <* external atomic__increment16 *> procedure increment16... <* external atomic__increment32 *> procedure increment32... <* external atomic__increment64 *> procedure increment64... const something := array of bitcount = {increment8, increment16, increment32, increment64} then you can maybe index into the array by the type size log 2 and call the function...and really really hope it gets optimized to a direct call. But on the other hand...if some versions have special inlining support in the compiler anyway, then you can also just teach the compiler about a size to function name mapping and still have an "external" (non-inlined function) implementation, just with compiler support to map the names. That seems like a reasonable compromise -- "compiler support to map the names". So I'm ok with no new language mechanism, but, of course, there is that philosophy -- build reusable mechanisms, not special cases. (This seems to be a guiding principle of C++ -- instead of special casing memory, all user defined types can have destructors; like the special built in numeric types, user defined types can overload operators and have type conversions, etc.) But often the reusable mechanism is much more difficult to design and implement than some special cases. - Jay > From: hosking at cs.purdue.edu > Date: Thu, 24 Dec 2009 10:35:07 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] external two level names? > > I don't understand the question. > > I have a pretty good idea how to implement atomic without that. > > On 24 Dec 2009, at 10:17, Jay K wrote: > > > Should we have a form of <*external*> that assumes two level > > names insead of one level names? > > > > This would be useful I believe for an initial implementation of Atomic. > > I don't see how to implement Atomic otherwise, well, other than a lame: > > > > Atomic.mg: > > if BYTESIZE(T) == 4 > > blah > > elsif BYTESIZE(T) == 8 > > blah > > > > which I guess is ok, or a switch. > > > > It'd also be very useful in the existing code base. > > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 29 18:47:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Dec 2009 18:47:48 +0100 Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option Message-ID: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> Any ideas? Interaction problem between threads and select? Olaf ----- Forwarded message from bugs at elego.de ----- Date: Tue, 29 Dec 2009 16:23:23 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1080: CVSUPD server hangs if used with -C option To: @MISSING_DOMAIN #1080: CVSUPD server hangs if used with -C option -----------------------------+---------------------------------------------- Reporter: rajeshvadivelu | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: Component: sys | Version: 5.8-RC3 Severity: critical | Keywords: Relnote: | Confidential: no Org: Collabnet | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | -----------------------------+---------------------------------------------- Htr: Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package. Start the cvsupd server with -C option ./cvsupd -b /data/cvsupd -C 2 Try cvsup client to connect to the sever ./cvsup -g -L 2 /tmp/cvsupd.cfg The client connection will hang and after sometime we will get "Inactivity timeout" Fix: Env: -----------------------------+---------------------------------------------- In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the cvsup installed. The server starts find and there was no issues if I start the server without -C option. Starting cvsupd server without -C option $ ./cvsupd -b /u2/site/data/cvsupd 2009.12.29 21:31:05 IST [6225]: CVSup server started 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0 2009.12.29 21:31:05 IST [6225]: Ready to service requests Then I did a client request as below $ ./cvsup -g -L 2 /tmp/cvsupd.cfg Parsing supfile "/tmp/cvsupd.cfg" Connecting to myserver.com Connected to myserver.com Rejected by server: Access denied Will retry at 21:37:09 So the request was successful and I get a valid error message at the client. But when I start the server with -C option like the one as below, requests from client are hanging and eventually getting "Inactivity timeout" after sometime. $ ./cvsupd -b /u2/site/data/cvsupd -C 2 When ever a new client connection was made, this daemon clones another cvsupd process and it also hangs. So none of the client request were processed. Strace of the main cvsupd server process, when a new client request was fired. ----------------------------------- select(4, [3], [], [3], {0, 39000}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0, 553000}) accept(3, {sa_family=AF_INET, sin_port=htons(51221), sin_addr=inet_addr("208.75.198.60")}, [16]) = 6 setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0 setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 gettimeofday({1262103026, 146476}, NULL) = 0 open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7 fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 _llseek(7, 0, [0], SEEK_CUR) = 0 fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 close(7) = 0 gettimeofday({1262103026, 147481}, NULL) = 0 stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No such file or directory) write(5, "\0", 1) = 1 futex(0x91580f0, FUTEX_WAKE, 1) = 1 futex(0x9158098, FUTEX_WAKE, 1) = 1 futex(0x91580b8, FUTEX_WAKE, 1) = 1 futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x9158098, FUTEX_WAKE, 1) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f43708) = 6543 futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1 futex(0x915a460, FUTEX_WAKE, 1) = 1 futex(0x91580f0, FUTEX_WAKE, 1) = 1 futex(0x9158098, FUTEX_WAKE, 1) = 1 futex(0x91580b8, FUTEX_WAKE, 1) = 1 futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x9158098, FUTEX_WAKE, 1) = 0 close(6) = 0 accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) select(4, [3], [], [3], {1, 0}) = 0 (Timeout) ------------------------------------ gdb backtrace of the main cvsupd server process ------------------------------------ #0 0x00a2a402 in __kernel_vsyscall () #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6 #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78, writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at ../src/unix/Common/UnixC.c:301 #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4, M3_A4bqCj_timeout=0xbfed9410) at ../src/thread/PTHREAD/ThreadPThread.m3:900 #4 0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c, M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:936 #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:854 #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48, M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458 #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at ../src/FSServer.m3:153 #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:399 #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:113 #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at ../src/runtime/common/RTLinker.m3:122 #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at _m3main.mc:4 ------------------------------------------------ strace of the cloned cvsupd process ----------------------------------- futex(0x91580bc, FUTEX_WAIT, 3, NULL ----------------------------------- gdb backtrace of the cloned cvsupd process ----------------------------------- #0 0x00a2a402 in __kernel_vsyscall () #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8, mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 #3 0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c, M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238 #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280 #5 0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc, M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105 #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243 #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at ../src/FSServer.m3:231 #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at ../src/FSServer.m3:227 #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:399 #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at ../src/runtime/common/RTLinker.m3:113 #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at ../src/runtime/common/RTLinker.m3:122 #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at _m3main.mc:4 ------------------------------------------- So it looks like both the main and cloned cvsupd processes were waiting for a response from the kernel call "__kernel_vsyscall ()". Under what condition will this happen? Am I doing something wrong here? -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 From rcolebur at SCIRES.COM Wed Dec 30 01:30:17 2009 From: rcolebur at SCIRES.COM (Randy Coleburn) Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages Message-ID: I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 14:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 13:10:55 +0000 Subject: [M3devel] build problems on 3 packages In-Reply-To: References: Message-ID: I haven't checked obliqparse or caltech-parser yet but I see what you mean in obliqrt. I haven't dug into it yet. == package /Users/jay/dev2/cm3/m3-obliq/obliqrt == +++ /cm3/bin/cm3 -build -override -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in AMD64_DARWIN --- ignoring override("obliqrt", "/Users/jay/dev2/cm3/m3-obliq") /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB "/Users/jay/dev2/cm3/m3-libs/m3core/src/text/Text.i3", line 16,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Real.i3", line 11,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/LongReal.i3", line 10,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Extended.i3", line 9,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/libm3/src/fmtlex/Fmt.i3", line 17,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/events/src/EventNumber.i3", line 78,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/sharedobj/src/SharedObj.i3", line 179,0: semantic analysis suppressed due to import errors "../src/ObValue.i3", line 6,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 1: /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB --procedure-- -line- -file--- exec -- _v_netobj 37 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobjv1 44 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobj 64 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl include_dir 45 /Users/jay/dev2/cm3/m3-obliq/obliqrt/src/m3makefile 9 /Users/jay/dev2/cm3/m3-obliq/obliqrt/AMD64_DARWIN/m3make.args Fatal Error: package build failed *** execution of [] failed *** - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 15:50:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 14:50:35 +0000 Subject: [M3devel] build problems on 3 packages In-Reply-To: References: , Message-ID: Please try again, thanks. These were presumably caught by tinderbox though I didn't check. - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Wed, 30 Dec 2009 13:10:55 +0000 Subject: Re: [M3devel] build problems on 3 packages I haven't checked obliqparse or caltech-parser yet but I see what you mean in obliqrt. I haven't dug into it yet. == package /Users/jay/dev2/cm3/m3-obliq/obliqrt == +++ /cm3/bin/cm3 -build -override -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in AMD64_DARWIN --- ignoring override("obliqrt", "/Users/jay/dev2/cm3/m3-obliq") /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB "/Users/jay/dev2/cm3/m3-libs/m3core/src/text/Text.i3", line 16,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Real.i3", line 11,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/LongReal.i3", line 10,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/m3core/src/float/IEEE/Extended.i3", line 9,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-libs/libm3/src/fmtlex/Fmt.i3", line 17,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/events/src/EventNumber.i3", line 78,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/sharedobj/src/SharedObj.i3", line 179,0: semantic analysis suppressed due to import errors "../src/ObValue.i3", line 6,0: semantic analysis suppressed due to import errors "/Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 1: /Users/jay/dev2/cm3/m3-comm/stubgen/AMD64_DARWIN/stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB --procedure-- -line- -file--- exec -- _v_netobj 37 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobjv1 44 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl netobj 64 /Users/jay/dev2/cm3/m3-comm/netobj/src/netobj.tmpl include_dir 45 /Users/jay/dev2/cm3/m3-obliq/obliqrt/src/m3makefile 9 /Users/jay/dev2/cm3/m3-obliq/obliqrt/AMD64_DARWIN/m3make.args Fatal Error: package build failed *** execution of [] failed *** - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 29 Dec 2009 19:30:17 -0500 Subject: [M3devel] build problems on 3 packages I've corrected a few build problems on the HEAD branch stemming from some recent changes. Now, I find that there are only 3 packages that fail to build for me: "m3-obliq\obliqrt" "m3-obliq\obliqparse" "caltech-parser\cit_util" I'm not sure exactly what has been changed recently to cause these build failures, but I think it is the changes introduced by Tony regarding the types et al. There was a message to the effect that these changes would force changes to the client code, so I suspect this is the case here. If Tony or someone can give more details about what has changed, I can probably make the fixes to these 3 modules. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 20:46:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2009 19:46:18 +0000 Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option In-Reply-To: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com> Message-ID: There should be nothing special about select and kernel threads, perhaps even select and user threads. The bug report is unusually good, though lacks the config file and the stacks of the other threads. Maybe more later.. - Jay > Date: Tue, 29 Dec 2009 18:47:48 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option > > Any ideas? Interaction problem between threads and select? > > Olaf > > ----- Forwarded message from bugs at elego.de ----- > Date: Tue, 29 Dec 2009 16:23:23 -0000 > From: CM3 > Reply-To: CM3 > Subject: [CM3] #1080: CVSUPD server hangs if used with -C option > To: @MISSING_DOMAIN > > #1080: CVSUPD server hangs if used with -C option > -----------------------------+---------------------------------------------- > Reporter: rajeshvadivelu | Owner: wagner > Type: sw-bug | Status: new > Priority: high | Milestone: > Component: sys | Version: 5.8-RC3 > Severity: critical | Keywords: > Relnote: | Confidential: no > Org: Collabnet | Estimatedhours: 0 > Hours: 0 | Billable: 0 > Totalhours: 0 | > -----------------------------+---------------------------------------------- > Htr: > Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package. > > Start the cvsupd server with -C option > > ./cvsupd -b /data/cvsupd -C 2 > > Try cvsup client to connect to the sever > > ./cvsup -g -L 2 /tmp/cvsupd.cfg > > The client connection will hang and after sometime we will get > "Inactivity timeout" > > > Fix: > > > > Env: > > > -----------------------------+---------------------------------------------- > In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs > repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the > cvsup installed. > > The server starts find and there was no issues if I start the server > without -C option. > > Starting cvsupd server without -C option > > $ ./cvsupd -b /u2/site/data/cvsupd > 2009.12.29 21:31:05 IST [6225]: CVSup server started > 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46 > 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0 > 2009.12.29 21:31:05 IST [6225]: Ready to service requests > > Then I did a client request as below > > $ ./cvsup -g -L 2 /tmp/cvsupd.cfg > Parsing supfile "/tmp/cvsupd.cfg" > Connecting to myserver.com > Connected to myserver.com > Rejected by server: Access denied > Will retry at 21:37:09 > > So the request was successful and I get a valid error message at the > client. > > But when I start the server with -C option like the one as below, requests > from client are hanging and eventually getting "Inactivity timeout" after > sometime. > > $ ./cvsupd -b /u2/site/data/cvsupd -C 2 > > When ever a new client connection was made, this daemon clones another > cvsupd process and it also hangs. So none of the client request were > processed. > > Strace of the main cvsupd server process, when a new client request was > fired. > > ----------------------------------- > select(4, [3], [], [3], {0, 39000}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0, 553000}) > accept(3, {sa_family=AF_INET, sin_port=htons(51221), > sin_addr=inet_addr("208.75.198.60")}, [16]) = 6 > setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0 > setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) > fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 > gettimeofday({1262103026, 146476}, NULL) = 0 > open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7 > fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 > _llseek(7, 0, [0], SEEK_CUR) = 0 > fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0 > close(7) = 0 > gettimeofday({1262103026, 147481}, NULL) = 0 > stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No > such file or directory) > write(5, "\0", 1) = 1 > futex(0x91580f0, FUTEX_WAKE, 1) = 1 > futex(0x9158098, FUTEX_WAKE, 1) = 1 > futex(0x91580b8, FUTEX_WAKE, 1) = 1 > futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0x9158098, FUTEX_WAKE, 1) = 0 > clone(child_stack=0, > flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0xb7f43708) = 6543 > futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1 > futex(0x915a460, FUTEX_WAKE, 1) = 1 > futex(0x91580f0, FUTEX_WAKE, 1) = 1 > futex(0x9158098, FUTEX_WAKE, 1) = 1 > futex(0x91580b8, FUTEX_WAKE, 1) = 1 > futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0x9158098, FUTEX_WAKE, 1) = 0 > close(6) = 0 > accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource temporarily > unavailable) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > select(4, [3], [], [3], {1, 0}) = 0 (Timeout) > > ------------------------------------ > > gdb backtrace of the main cvsupd server process > > ------------------------------------ > > #0 0x00a2a402 in __kernel_vsyscall () > #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6 > #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78, > writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at > ../src/unix/Common/UnixC.c:301 > #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4, > M3_A4bqCj_timeout=0xbfed9410) at > ../src/thread/PTHREAD/ThreadPThread.m3:900 > #4 0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c, > M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:936 > #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3, > M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at > ../src/thread/PTHREAD/ThreadPThread.m3:854 > #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48, > M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458 > #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at > ../src/FSServer.m3:153 > #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 > #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:399 > #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:113 > #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at > ../src/runtime/common/RTLinker.m3:122 > #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at > _m3main.mc:4 > ------------------------------------------------ > > > strace of the cloned cvsupd process > > ----------------------------------- > > futex(0x91580bc, FUTEX_WAIT, 3, NULL > > ----------------------------------- > > gdb backtrace of the cloned cvsupd process > > ----------------------------------- > > #0 0x00a2a402 in __kernel_vsyscall () > #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/libpthread.so.0 > #2 0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8, > mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326 > #3 0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c, > M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238 > #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8, > M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280 > #5 0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc, > M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105 > #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243 > #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at > ../src/FSServer.m3:231 > #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at > ../src/FSServer.m3:227 > #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336 > #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:399 > #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at > ../src/runtime/common/RTLinker.m3:113 > #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at > ../src/runtime/common/RTLinker.m3:122 > #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at > _m3main.mc:4 > > ------------------------------------------- > > So it looks like both the main and cloned cvsupd processes were waiting > for a response from the kernel call "__kernel_vsyscall ()". Under what > condition will this happen? Am I doing something wrong here? > > -- > Ticket URL: > CM3 > Critical Mass Modula3 Compiler > > > ----- End forwarded message ----- > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: