[MLton] Re: exene example

[Lukasz S Ziarek]

On Wed, 31 Aug 2005, Matthew Fluet wrote:

>
>> My suggestion, if you need to modify the Basis Library and CML Library, 
>> would be to isolate your work in a directory:
>> 
>> /homes/lziarek/stabalize/code/mlton.eXene
>> 
>> with a full check-out of the MLton source tree.  Make your modifications to 
>> the Basis Library and the CML Library in
>> 
>> /homes/lziarek/stabalize/code/mlton.eXene/basis-library
>> /homes/lziarek/stabalize/code/mlton.eXene/lib/cml-lib
>> 
>> respectively.  Build MLton (i.e., make all) in your mlton.eXene directory.
>> 
>> Update your eXene port to use $(SML_LIB)/basis and $(SML_LIB)/cml-lib 
>> instead of absolute paths.  When you want to compile and test an eXene 
>> example, make sure that you invoke:
>>  /homes/lziarek/stabalize/code/mlton.eXene/build/bin/mlton
>> That will ensure that you are compiling with $(SML_LIB) pointing to your 
>> modified libraries.
>> 
>> If you need to make further modifications to the Basis Library or the CML 
>> Library, you will need to do "make basis libraries" afterward to propagate 
>> your changes to the build/lib/sml directory, which is where $(SML_LIB) will 
>> be pointing.  That will be much quicker than "make all".
>
> I followed through on this approach, adding PackWord16 to the Basis Library 
> and rooting all paths at $(SML_LIB).  I ended up making no changes to the CML 
> Library, as the only changes there appear to be to work around the typing 
> problems introduced by duplicating the Basis Library.
>
>
>> To build a runable with
>> exene, simply go to portExene/eXene/examples/triangle  and build the
>> sources.mlb there.  To edit the triangles example edit mltontri.sml.  This
>> verion of exene dumps a lot of output to the screen, what you are looking 
>> for
>> is:
>> 
>> exenedebugphil: xio ending bc of SysErr txt=(Interrupted system call)
>> msg=(Interrupted system call) name=intr)  thrown in xio
>
> [fluet@localhost triangle]$ ~/mlton/mlton.eXene/build/bin/mlton sources.mlb
> Warning: ../../lib/protocol/xio.sml 559.10.
>  Function is not exhaustive.
> ...
> [fluet@localhost triangle]$ ./sources
> xshutdown.sml: removed RunCML.logChannel. might have been important - seems 
> OK for now LUKE
> mltonTriPhil: host is ''
> StubTraceCML:/:xspawn triangle [000001]
> TriDebug: about to run triangle
> TriDebug: opening cml and interact
> TriDebug: alloc windows start
> TriDebug: init dpy start
> ...
> exenedebugphil:xio.getMsg start
> exenedebugphil:xio.readVec start
> exenedebugphil:xio.readVec before socket
> exenedebugphil:xio.readVec n=32
> exenedebugphil: check about to exec
>
> At this point it just seems to hang.  Running with strace yields:
>
> [fluet@localhost triangle]$ strace ./sources
> execve("./sources", ["./sources"], [/* 49 vars */]) = 0
> [ Process PID=9908 runs in 32 bit mode. ]
> brk(0)                                  = 0x8206000
> ...
> write(1, "eXeneDebugLuke: making screens\n", 31eXeneDebugLuke: making screens
> ) = 31
> --- SIGALRM (Alarm clock) @ 0 (0) ---
> sigreturn()                             = 31
> rt_sigprocmask(SIG_BLOCK, [], [], 8)    = 0
> rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], [ALRM], 8) = 0
> write(1, "exenedebugphil:xio.getMsg start\n", 32exenedebugphil:xio.getMsg 
> start
> ) = 32
> write(1, "exenedebugphil:xio.readVec start"..., 33exenedebugphil:xio.readVec 
> start
> ) = 33
> write(1, "exenedebugphil:xio.readVec befor"..., 41exenedebugphil:xio.readVec 
> before socket
> ) = 41
> write(1, "exenedebugphil:xio.readVec n=32\n", 32exenedebugphil:xio.readVec 
> n=32
> ) = 32
> write(1, "exenedebugphil: check about to e"..., 36exenedebugphil: check about 
> to exec
> ) = 36
> socketcall(0xa, 0xffffd748)             = ? ERESTARTSYS (To be restarted)
> --- SIGALRM (Alarm clock) @ 0 (0) ---
> sigreturn()                             = -1 EINTR (Interrupted system call)
> rt_sigprocmask(SIG_BLOCK, [], [], 8)    = 0
> rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
> socketcall(0xa, 0xffffd748
>
> At this point it just seems to hang again.
>
> I'm not quite sure whether or not this is the right behavior.  I would think 
> that the socket call should succeed in some fashion, but it doesn't appear to 
> be making any progress.
>

For debuging purposes we set the time slice to 20 seconds so that the 
thread interleavings would not be so great, slightly easier to see what 
is going on since eXene does use a decent amount of threads.  So if the 
socket call blocks, it will wait for a few seconds (or 20) before context 
switching, which is probably the behavoir you are seeing.  Though 
as soon as it does it should throw the exception, which our handler prints 
(but I am not sure if this verions reraises it or not).  There are tons of 
handle _ => ... handlers in eXene so you might need to modify a few to get 
it to propogate to top level.

thanks
Luke