From wesley at terpstra.ca Thu Aug 20 07:52:24 2009 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Thu Aug 20 07:52:58 2009 Subject: [MLton] Unsafe Pack{Word,Real} Message-ID: <162de7480908200752w47476eb8g2e49cba8e6576240@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: unsafe-pack.patch Type: text/x-patch Size: 11858 bytes Desc: not available Url : http://mlton.org/pipermail/mlton/attachments/20090820/ecd630ae/unsafe-pack.bin From fluet at tti-c.org Fri Aug 21 05:11:53 2009 From: fluet at tti-c.org (Matthew Fluet) Date: Fri Aug 21 05:11:57 2009 Subject: [MLton] Unsafe Pack{Word,Real} In-Reply-To: <162de7480908200752w47476eb8g2e49cba8e6576240@mail.gmail.com> References: <162de7480908200752w47476eb8g2e49cba8e6576240@mail.gmail.com> Message-ID: On Thu, 20 Aug 2009, Wesley W. Terpstra wrote: > Does anyone have an objection to this patch? The concept is fine, but the implementation ends up duplicating significant functionality from the PACK_{REAL,WORD} structures. It might be better to work similar to the way the UnsafeMono{Array,Vector} functors work --- rebind elements of an _EXTRA structure: functor UnsafePackWord (PW: PACK_WORD_EXTRA) : PACK_WORD = structure open PW val subVec = unsafeSubVec val subVecX = unsafeSubVecX val subArr = unsafeSubArr val subArrX = unsafeSubArrX val update = unsafeUpdate end Now, in the original PackWord functor bind the unsafe versions of the functions to unsafe* and use them in the safe versions. From wesley at terpstra.ca Fri Aug 21 06:12:42 2009 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Fri Aug 21 06:13:16 2009 Subject: [MLton] Unsafe Pack{Word,Real} In-Reply-To: References: <162de7480908200752w47476eb8g2e49cba8e6576240@mail.gmail.com> Message-ID: <162de7480908210612j726eb8b8ob96744d425bfedac@mail.gmail.com> On Fri, Aug 21, 2009 at 2:11 PM, Matthew Fluet wrote: > The concept is fine, but... it might be better to ... rebind elements of an > _EXTRA structure. Revised and committed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton/attachments/20090821/a1cb754c/attachment.htm From fluet at tti-c.org Fri Aug 21 07:44:26 2009 From: fluet at tti-c.org (Matthew Fluet) Date: Fri Aug 21 07:44:30 2009 Subject: [MLton] Re: [MLton-commit] r7221 In-Reply-To: References: Message-ID: On Fri, 21 Aug 2009, Wesley Terpstra wrote: > =================================================================== > --- mlton/trunk/basis-library/libs/basis-extra/top-level/basis.sig 2009-08-20 13:40:52 UTC (rev 7220) > +++ mlton/trunk/basis-library/libs/basis-extra/top-level/basis.sig 2009-08-21 12:47:54 UTC (rev 7221) > @@ -380,6 +380,19 @@ > sharing Unsafe.Word32Vector = Word32Vector > sharing Unsafe.Word64Array = Word64Array > sharing Unsafe.Word64Vector = Word64Vector > + sharing Unsafe.Word64Vector = Word64Vector Duplication of sharing constraint. From wesley at terpstra.ca Fri Aug 21 08:19:05 2009 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Fri Aug 21 08:19:38 2009 Subject: [MLton] Re: [MLton-commit] r7221 In-Reply-To: References: Message-ID: <162de7480908210819k323b0c9ayb1c0c950051f7a3@mail.gmail.com> On Fri, Aug 21, 2009 at 4:44 PM, Matthew Fluet wrote: > On Fri, 21 Aug 2009, Wesley Terpstra wrote: > >> sharing Unsafe.Word64Vector = Word64Vector >> + sharing Unsafe.Word64Vector = Word64Vector >> > > Duplication of sharing constraint. :-P -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton/attachments/20090821/53f0d88d/attachment.html From Nicolas.Bertolotti at mathworks.fr Thu Aug 27 08:06:12 2009 From: Nicolas.Bertolotti at mathworks.fr (Nicolas Bertolotti) Date: Thu Aug 27 08:07:01 2009 Subject: [MLton] Problem with the setitimer() emulation for MinGW Message-ID: <8320D98DA9A5C54C926D397795FE7CEA64B652D99D@EXCHANGE-UK.ad.mathworks.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2748 bytes Desc: image001.jpg Url : http://mlton.org/pipermail/mlton/attachments/20090827/1f831b16/image001.jpg From wesley at terpstra.ca Sun Aug 30 15:39:02 2009 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Sun Aug 30 15:39:08 2009 Subject: [MLton] Problem with the setitimer() emulation for MinGW In-Reply-To: <8320D98DA9A5C54C926D397795FE7CEA64B652D99D@EXCHANGE-UK.ad.mathworks.com> References: <8320D98DA9A5C54C926D397795FE7CEA64B652D99D@EXCHANGE-UK.ad.mathworks.com> Message-ID: <162de7480908301539s2678ba16oef9c134a16280bc9@mail.gmail.com> On Thu, Aug 27, 2009 at 5:06 PM, Nicolas Bertolotti < Nicolas.Bertolotti@mathworks.fr> wrote: > I am facing strange crashes of the MinGW version of my application when > using the TimeLimit structure > What is the "TimeLimit" structure? MLton exposes access to this functionality only via the MLton.Itimer structure. > which relies on the setitimer implementation (MLton compiler based on the > current SVN sources). > Can you provide a small demonstration program? Which version of Windows? > When I run a function using TimeLimit, the process actually crashes about > 10 seconds after the timer is initialized before the TimeLimit call > completes (even if the function I run through TimeLimit requires much less > than 10 seconds to complete). > Is 10 seconds a special value in your program? > I noticed that the issue disappears if I comment out the > SetThreadPriority() call in the fixPriority() function (file > runtime/platform/mingw.c) and call : > > SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_BELOW_NORMAL); > > instead from the main thread. > Well, removing the line completely will just decrease the responsiveness of the timers. Setting the main thread to higher priority will decrease responsiveness even further. Is it possible that this decreased responsiveness masks some phenomenon in your program which relates to this awfully special sounding 10s? A race condition perhaps? > I can?t find out a reason why the system would let us change the priority > of the timer thread (the function returns TRUE) but adopt a strange behavior > after than but it definitely seems to be the case. > I'm unconvinced that Windows would have a bug like this. I get the vague impression that you might be using the MLton implementation of setitimer directly... If that is the case, it probably is also the source of your problems. The "signal handler" run by setitimer does not run in the main thread, greatly restricting what one can safely do. MLton itself only uses the handle to set a flag. I suggest you do the same. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton/attachments/20090831/a2b2c2c7/attachment.htm From Nicolas.Bertolotti at mathworks.fr Mon Aug 31 01:34:16 2009 From: Nicolas.Bertolotti at mathworks.fr (Nicolas Bertolotti) Date: Mon Aug 31 01:34:57 2009 Subject: [MLton] Problem with the setitimer() emulation for MinGW In-Reply-To: <162de7480908301539s2678ba16oef9c134a16280bc9@mail.gmail.com> References: <8320D98DA9A5C54C926D397795FE7CEA64B652D99D@EXCHANGE-UK.ad.mathworks.com> <162de7480908301539s2678ba16oef9c134a16280bc9@mail.gmail.com> Message-ID: <8320D98DA9A5C54C926D397795FE7CEA7AAE995C9C@EXCHANGE-UK.ad.mathworks.com> TimeLimit is included in smlnj-lib/Util. It uses the structure Engine (same location) which itself relies on MLton.Itimer. 10 seconds means nothing for my program. The time limit I set is 30 minutes. The computation we perform in the application is pure mathematics (no system calls expect to read or write some files to the disk, no dependency against some particular FFI functions ...). There is no direct use of the setitimer() function and all the system calls that are performed internally by MLton. Please note that I also could not manage to extract a sample program that reproduces the issue (I experienced it using Windows XP) ... it would have been too easy. From: Wesley W. Terpstra [mailto:wesley@terpstra.ca] Sent: Monday, August 31, 2009 12:39 AM To: Nicolas Bertolotti Cc: mlton@mlton.org Subject: Re: [MLton] Problem with the setitimer() emulation for MinGW On Thu, Aug 27, 2009 at 5:06 PM, Nicolas Bertolotti > wrote: I am facing strange crashes of the MinGW version of my application when using the TimeLimit structure What is the "TimeLimit" structure? MLton exposes access to this functionality only via the MLton.Itimer structure. which relies on the setitimer implementation (MLton compiler based on the current SVN sources). Can you provide a small demonstration program? Which version of Windows? When I run a function using TimeLimit, the process actually crashes about 10 seconds after the timer is initialized before the TimeLimit call completes (even if the function I run through TimeLimit requires much less than 10 seconds to complete). Is 10 seconds a special value in your program? I noticed that the issue disappears if I comment out the SetThreadPriority() call in the fixPriority() function (file runtime/platform/mingw.c) and call : SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_BELOW_NORMAL); instead from the main thread. Well, removing the line completely will just decrease the responsiveness of the timers. Setting the main thread to higher priority will decrease responsiveness even further. Is it possible that this decreased responsiveness masks some phenomenon in your program which relates to this awfully special sounding 10s? A race condition perhaps? I can't find out a reason why the system would let us change the priority of the timer thread (the function returns TRUE) but adopt a strange behavior after than but it definitely seems to be the case. I'm unconvinced that Windows would have a bug like this. I get the vague impression that you might be using the MLton implementation of setitimer directly... If that is the case, it probably is also the source of your problems. The "signal handler" run by setitimer does not run in the main thread, greatly restricting what one can safely do. MLton itself only uses the handle to set a flag. I suggest you do the same. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton/attachments/20090831/189d3456/attachment.html From wesley at terpstra.ca Mon Aug 31 10:58:32 2009 From: wesley at terpstra.ca (Wesley W. Terpstra) Date: Mon Aug 31 10:59:08 2009 Subject: [MLton] Problem with the setitimer() emulation for MinGW In-Reply-To: <8320D98DA9A5C54C926D397795FE7CEA7AAE995C9C@EXCHANGE-UK.ad.mathworks.com> References: <8320D98DA9A5C54C926D397795FE7CEA64B652D99D@EXCHANGE-UK.ad.mathworks.com> <162de7480908301539s2678ba16oef9c134a16280bc9@mail.gmail.com> <8320D98DA9A5C54C926D397795FE7CEA7AAE995C9C@EXCHANGE-UK.ad.mathworks.com> Message-ID: <162de7480908311058r1765890ax6a8e4c0311e1e855@mail.gmail.com> On Mon, Aug 31, 2009 at 10:34 AM, Nicolas Bertolotti < Nicolas.Bertolotti@mathworks.fr> wrote: > TimeLimit is included in smlnj-lib/Util. It uses the structure Engine > (same location) which itself relies on MLton.Itimer. > Ahh, I see. I have never used smlnj-lib myself. > 10 seconds means nothing for my program. The time limit I set is 30 > minutes. > Is the time it takes to fail the same on computers with different processing speeds? ie: on a computer twice as slow will it crash in 20 seconds or still 10 seconds? > The computation we perform in the application is pure mathematics > This is very odd. It reproducibly fails after 10s each time? What is the failure message anyway? One way to debug the problem might be to watch what system calls the program is doing right before it dies. There are a few tools for windows that work like 'strace' in Unix. I've found them useful in debugging problems like this in my own programs, but I don't recall the name of the one I used most recently. I think it may have been straceNT [1]. Please note that I also could not manage to extract a sample program that > reproduces the issue (I experienced it using Windows XP) ? it would have > been too easy. > If you could try slowly eliminating your program until the problem disappears, we might find what the interaction is. [1] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mlton.org/pipermail/mlton/attachments/20090831/8d1b7a41/attachment.htm