<div class="gmail_quote">On Thu, Aug 27, 2009 at 5:06 PM, Nicolas Bertolotti <span dir="ltr"><<a href="mailto:Nicolas.Bertolotti@mathworks.fr">Nicolas.Bertolotti@mathworks.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="FR"><div>
<span lang="EN-US">I am facing strange crashes of the MinGW
version of my application when using the TimeLimit structure</span></div></div></blockquote><div><br>What is the "TimeLimit" structure? MLton exposes access to this functionality only via the MLton.Itimer structure.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="FR"><div><span lang="EN-US"> which relies on
the setitimer implementation (MLton compiler based on the current SVN sources).</span>
</div></div></blockquote><div><br>Can you provide a small demonstration program? Which version of Windows?<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="FR"><div>
<p><span lang="EN-US">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).</span></p></div></div></blockquote><div>Is 10 seconds a special value in your program?<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="FR"><div><p><span lang="EN-US"></span></p>
<p><span lang="EN-US">I noticed that the issue disappears if I
comment out the SetThreadPriority() call in the fixPriority() function (file
runtime/platform/mingw.c) and call :</span></p>
<p><span lang="EN-US">SetThreadPriority(GetCurrentThread(),
THREAD_PRIORITY_BELOW_NORMAL);</span></p>
<p><span lang="EN-US">instead from the main thread.</span></p></div></div></blockquote><div>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. <br>
<br>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?<span lang="EN-US"><br></span></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="FR"><div><p><span lang="EN-US"></span></p>
<p><span lang="EN-US">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.</span><br></p></div></div></blockquote><div>I'm unconvinced that Windows would have a bug like this.<br><br>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.<br>
<br></div></div>