[M3devel] Status of threads for RC4?

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Thu Oct 15 10:27:56 CEST 2009


Hi all:
I was merely thinking how we could mitigate the issue in threading.
We could argue the current thread implementation issues on NT are worrisome but, the system performance is more important and I guess a release is waiting  for all platforms stability.
I think we could make a work around to put some tests on the GUI subsystem on the test suite, using the sort of capability that Zeus Mentor Snapshot has to capture the screen shot and compare with others results with test already on:
m3-ui/ui-tests
m3-ui/ui/test
Just getting some sort of difference between NT GUI subsystem and X implementation would allows to see where we can be missing something.
Also integration on X implementation of Critical mass GUI upgrade would be highly appreciated: cm3-cvs/m3-ui/cmvbt
Also I remember I saw the pm3 NT386GNU target implementation doing basic stuff with DEC SRC NT GUI, but  another doing advanced stuff with Mentor and others I think  the code you can get it by the package/src/ directories (http://www.1o0.de/wi-links/modula3/), but I´m not aware if it used the x/cygwin, I don´t think so, but even if so, would be an advance to have mentor running animation stuff until some point we could get better performance in the current NT GUI implementation (could be something in the garbage collection, Tony, as NT has its own garbage collector, has it been maintained after CM3 developed the new collector?)
Another shot maybe for next release (7.0) is trying to develop tests on obliq framework and integration with pm3 documentation system, which seemed to be good.
About Unix interfaces, Im thinking how to reuse the SPIN digital Unix interface so we can have a sort of a virtualization tool integrated in CM3 as a tool for deploying Unix apps on NT and getting some layers of Modula-3 runtime code based on a standarized Unix interface Sphinx.i3 (path in spin sources tree user/sphinx/src/IX86_SPIN/) something we could call "DECUnix.i3", we could also get some parts of the system running directly over Modula-3 runtime code rather than on bare Unix interfaces getting a more standarized behaviuor and maybe we could gain some knowledge to do experiments for system developers and users

Thanks in advance

--- El mié, 14/10/09, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Status of threads for RC4?
Para: "Olaf" <wagner at elegosoft.com>, "Tony" <hosking at cs.purdue.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: miércoles, 14 octubre, 2009 6:13




I didn't deliberately turn anything off but indeed I can see that some machines are not accessible and some are. I'll look at them later.

 

 - Jay
 
> Date: Wed, 14 Oct 2009 08:09:56 +0200
> From: wagner at elegosoft.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Status of threads for RC4?
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > I need to see all the threads:
> >
> > thread apply all bt
> 
> Well, of course you need all thread stacks to diagnose a deadlock,
> silly me. But I haven't been able to login again since then:
> Jay, is the OpenBSD server turned off? Could you either turn it on
> this evening CET or send Tony the needed traces?
> 
> Thanks in advance,
> 
> Olaf
> 
> > On 13 Oct 2009, at 02:46, Olaf Wagner wrote:
> >
> >> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> >>
> >>> I need a stack dump from the hung OpenBSD p007 run to diagnose (attach
> >>> to the process using gdb and grab a stack dump). Are we seeing this
> >>> on any other pthread target?
> >>
> >> I just logged in quickly to Jay's OpenBSD system and started test 7.
> >> Output stops after line 8 and I had to hit Control-C.
> >>
> >>
> >> bash-3.2$ m3gdb src/p0/p007/I386_OPENBSD/pgm
> >> GNU gdb plus Modula-3 6.4
> >> Copyright 2005 Free Software Foundation, Inc.
> >> GDB is free software, covered by the GNU General Public License, 
> >> and you are
> >> welcome to change it and/or distribute copies of it under certain 
> >> conditions.
> >> Type "show copying" to see the conditions.
> >> There is absolutely no warranty for GDB. Type "show warranty" for details.
> >> This GDB was configured as "i686-openbsd"...
> >> (m3gdb) r
> >> Starting program: /home/hudson/workspace/cm3-test-m3tests- 
> >> I386_OPENBSD/cm3/m3-sys/m3tests/src/p0/p007/I386_OPENBSD/pgm
> >>
> >> 1: 1
> >> 2: 1 2
> >> 3: 1 2 3
> >> 4: 1 2 3 4
> >> 5: 1 2 3 4 5
> >> 6: 1 2 3 4 5 6
> >> 7: 1 2 3 4 5 6 7
> >> 8: 1 2 3 4 5 6 7 8
> >> 9: ^C
> >> Program received signal SIGINT, Interrupt.
> >> 0x0e3f18f1 in poll () from /usr/lib/libc.so.50.1
> >> (m3gdb) bt
> >> #0 0x0e3f18f1 in poll () from /usr/lib/libc.so.50.1
> >> #1 0x0910f314 in _thread_kern_poll (wait_reqd=1)
> >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:760
> >> #2 0x0910ee53 in _thread_kern_sched (scp=0x0)
> >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:382
> >> #3 0x0910f19f in _thread_kern_sched_state (state=688918728,
> >> fname=0x291010c8 "", lineno=688918728)
> >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:550
> >> #4 0x09109085 in nanosleep (time_to_sleep=0x8544ec68,
> >> time_remaining=0x8544ec70)
> >> at /usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84
> >> #5 0x1c023181 in ThreadPThread__Nanosleep (req=0x8544ec68, rem=0x8544ec70)
> >> at ../src/thread/PTHREAD/ThreadPThreadC.c:317
> >> #6 0x1c01fb54 in CommonSleep () at ../src/thread/PTHREAD/ 
> >> ThreadPThread.m3:740
> >> #7 0x1c0219d3 in StopWorld () at ../src/thread/PTHREAD/ 
> >> ThreadPThread.m3:1253
> >> #8 0x1c021041 in SuspendOthers ()
> >> at ../src/thread/PTHREAD/ThreadPThread.m3:1029
> >> #9 0x1c007ccb in CollectSomeInStateZero ()
> >> at ../src/runtime/common/RTCollector.m3:735
> >> #10 0x1c007c8a in CollectSome () at ../src/runtime/common/ 
> >> RTCollector.m3:709
> >> #11 0x1c00773d in CollectEnough () at ../src/runtime/common/ 
> >> RTCollector.m3:643
> >> #12 0x1c004de1 in AllocTraced (dataSize=Invalid C/C++ type code 40 
> >> in symbol table.
> >> )
> >> at ../src/runtime/common/RTAllocator.m3:363
> >> #13 0x1c004056 in GetTracedObj (def=Invalid C/C++ type code 29 in 
> >> symbol table.
> >> )
> >> at ../src/runtime/common/RTAllocator.m3:222
> >> #14 0x1c0039ec in AllocateTracedObj (defn=Invalid C/C++ type code 
> >> 35 in symbol table.
> >> )
> >> at ../src/runtime/common/RTAllocator.m3:120
> >> #15 0x1c002b82 in Task (self=Invalid C/C++ type code 26 in symbol table.
> >> ) at ../Main.m3:58
> >> #16 0x1c01ed3e in RunThread (me=Invalid C/C++ type code 29 in symbol table.
> >> )
> >> at ../src/thread/PTHREAD/ThreadPThread.m3:588
> >> #17 0x1c01ea83 in ThreadBase (param=Invalid C/C++ type code 35 in 
> >> symbol table.
> >> )
> >> at ../src/thread/PTHREAD/ThreadPThread.m3:564
> >> #18 0x0910637f in _thread_start ()
> >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240
> >> #19 0x0000002b in ?? ()
> >> #20 0x00000000 in ?? ()
> >> (m3gdb) set lang Modula-3
> >> (m3gdb) bt
> >> #0 0x0e3f18f1 in poll () from /usr/lib/libc.so.50.1
> >> #1 0x0910f314 in _thread_kern_poll (wait_reqd=1)
> >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:760
> >> #2 0x0910ee53 in _thread_kern_sched (scp=0x0)
> >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:382
> >> #3 0x0910f19f in _thread_kern_sched_state (state=688918728,
> >> fname=0x291010c8 "\000", lineno=688918728)
> >> at /usr/src/lib/libpthread/uthread/uthread_kern.c:550
> >> #4 0x09109085 in nanosleep (time_to_sleep=0x8544ec68,
> >> time_remaining=0x8544ec70)
> >> at /usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84
> >> #5 0x1c023181 in ThreadPThread__Nanosleep (req=0x8544ec68, rem=0x8544ec70)
> >> at ../src/thread/PTHREAD/ThreadPThreadC.c:317
> >> #6 0x1c01fb54 in CommonSleep () at ../src/thread/PTHREAD/ 
> >> ThreadPThread.m3:740
> >> #7 0x1c0219d3 in StopWorld () at ../src/thread/PTHREAD/ 
> >> ThreadPThread.m3:1253
> >> #8 0x1c021041 in SuspendOthers ()
> >> at ../src/thread/PTHREAD/ThreadPThread.m3:1029
> >> #9 0x1c007ccb in CollectSomeInStateZero ()
> >> at ../src/runtime/common/RTCollector.m3:735
> >> #10 0x1c007c8a in CollectSome () at ../src/runtime/common/ 
> >> RTCollector.m3:709
> >> #11 0x1c00773d in CollectEnough () at ../src/runtime/common/ 
> >> RTCollector.m3:643
> >> #12 0x1c004de1 in AllocTraced (dataSize=12, dataAlignment=4, thread=
> >> RECORD inCritical = 0; pool = RECORD note = Allocated; pure = 
> >> FALSE; page = NIL; next = NIL; limit = NIL; END; END)
> >> at ../src/runtime/common/RTAllocator.m3:363
> >> #13 0x1c004056 in GetTracedObj (def=16_3c001114)
> >> at ../src/runtime/common/RTAllocator.m3:222
> >> #14 0x1c0039ec in AllocateTracedObj (defn=16_3c001114)
> >> at ../src/runtime/common/RTAllocator.m3:120
> >> #15 0x1c002b82 in Task (self=16_8bc4a00c) at ../Main.m3:58
> >> #16 0x1c01ed3e in RunThread (me=16_7faae480)
> >> at ../src/thread/PTHREAD/ThreadPThread.m3:588
> >> #17 0x1c01ea83 in ThreadBase (param=16_7faae480)
> >> at ../src/thread/PTHREAD/ThreadPThread.m3:564
> >> #18 0x0910637f in _thread_start ()
> >> at /usr/src/lib/libpthread/uthread/uthread_create.c:240
> >> #19 0x0000002b in ?? ()
> >> #20 0x00000000 in ?? ()
> >> (m3gdb)
> >>
> >> Attaching to a running program doesn't yield anything useful:
> >>
> >> bash-3.2$ src/p0/p007/I386_OPENBSD/pgm &
> >> [1] 26756
> >> bash-3.2$
> >> 1: 1
> >> 2: 1 2
> >> 3: 1 2 3
> >> 4: 1 2 3 4
> >> 5: 1 2 3 4 5
> >> 6: 1 2 3 4 5 6
> >> 7: 1 2 3 4 5 6 7
> >> 8: 1 2 3 4 5 6 7 8
> >> 9:
> >> bash-3.2$ ps
> >> PID TT STAT TIME COMMAND
> >> 22500 p0 Is 0:00.00 -ksh (ksh)
> >> 18592 p0 S 0:00.04 bash
> >> 26756 p0 S 0:00.02 src/p0/p007/I386_OPENBSD/pgm
> >> 28998 p0 R+ 0:00.00 ps
> >> bash-3.2$ m3gdb
> >> GNU gdb plus Modula-3 6.4
> >> Copyright 2005 Free Software Foundation, Inc.
> >> GDB is free software, covered by the GNU General Public License, 
> >> and you are
> >> welcome to change it and/or distribute copies of it under certain 
> >> conditions.
> >> Type "show copying" to see the conditions.
> >> There is absolutely no warranty for GDB. Type "show warranty" for details.
> >> This GDB was configured as "i686-openbsd".
> >> (m3gdb) attach 26756
> >> Attaching to process 26756
> >> 0x0d35f8f1 in ?? ()
> >> (m3gdb) set symbol-file src/p0/p007/I386_OPENBSD/pgm
> >> No symbol table is loaded. Use the "file" command.
> >> (m3gdb) symbol-file src/p0/p007/I386_OPENBSD/pgm
> >> Reading symbols from /home/hudson/workspace/cm3-test-m3tests- 
> >> I386_OPENBSD/cm3/m3-sys/m3tests/src/p0/p007/I386_OPENBSD/pgm...done.
> >> (m3gdb) bt
> >> #0 0x0d35f8f1 in ?? ()
> >> #1 0x0a0c0314 in ?? ()
> >> #2 0x84533000 in ?? ()
> >> #3 0x00000001 in ?? ()
> >> #4 0x00000001 in ?? ()
> >> #5 0x00000001 in ?? ()
> >> #6 0x00000000 in ?? ()
> >>
> >> Does this help?
> >> Anything I should try this evening?
> >>
> >> 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
> >>
> 
> 
> 
> -- 
> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091015/722e9140/attachment-0002.html>


More information about the M3devel mailing list