<div dir="ltr">Hi Andreas,<div><br></div><div> I just read the OpenSolaris sigaction manual page and it has the expected semantics with SA_RESETHAND; i.e. one does /not/ have to do anything special to avoid having to reset the handler. So I wonder whether ioInitHeartbeat is even being called. You might check. It ends with a call of setIntervalTimer(beatMilliseconds) which should set the heartbeat itimer going.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 11:28 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Andreas,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 9:58 AM, Andreas Wacknitz <span dir="ltr"><<a href="mailto:a.wacknitz@gmx.de" target="_blank">a.wacknitz@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div style="word-wrap:break-word"><br><div><div>Am 24.04.2014 um 00:14 schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:</div>
<br><blockquote type="cite"><div dir="ltr">Hi Andreas,<div class="gmail_extra"><br><br><div class=""><div class="gmail_quote">On Wed, Apr 23, 2014 at 9:35 AM, Andreas Wacknitz <span dir="ltr"><<a href="mailto:a.wacknitz@gmx.de" target="_blank">a.wacknitz@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div style="word-wrap:break-word">Thanks again Eliot,<div>
<br></div><div>First, I solved the pthreads problem under OpenSolaris. While Solaris 10 doesn’t need special user privileges for thread control (at least within the same thread policy I guess),</div><div>users under Solaris 11 (and thus OpenSolaris) need the privilege „proc_priocntl“ to be given by an administrator.</div>
<div>(For those who are interested: usermod -K defaultpriv=basic,proc_priocntl andreas)</div></div></blockquote><div><br></div><div>This is a pain :-). You could either assume that people can always get the necessary permission and go with the threaded heartbeat (my preferred suggestion) or provide two VMs (always tedious).</div>
</div></div></div></div></blockquote>Yes, I consider going with the threaded heartbeat for OpenSolaris (I will also try to compile everything under Solaris 11.1 but that’s on lower priority for me as I am not really using it.).</div>
<div>I am not yet decided whether the version without increased priority would be enough. At the moment everything seems to run fine with this version; I can interrupt "[[true] whileTrue] forkAt: Processor userInterruptPriority“</div>
<div>by ALT-.</div></div></blockquote><div><br></div><div>That implies it is working. But I would definitely make sure the heartbeat runs at a higher priority than the main thread.</div><div><br></div><div>One thing to check is that delays expire even when the system is fully busy, e.g.</div>
<div><br></div><div>| run s |</div><div>run := true.</div><div>s := Semaphore new.</div><div>[| i | i := 0. s wait. [run] whileTrue: [i := i + 1]] forkAt: Processor highestPriority - 1.</div><div>[(Delay forSeconds: 1) wait. run := false] forkAt: Processor highestPriority.</div>
<div>s signal</div><div><br></div><div>should lock up the system for 1 second. If the heartbeat is not advancing the clock used to check for delays then the sytsem will remain locked.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>But the whole thing isn’t finished yet as FFI (NativeBoost doesn’t seem to work (e.g. "UnixEnvironment environ“ fails. I don’t know when I will find time to deal with that.</div>
</div></blockquote><div><br></div><div>Well, the code is still useful for the Squeak VM, so please commit if and when you have the heartbeat working to your satisfaction.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>More below…<br>
</div><div><br><div><div>Am 22.04.2014 um 22:31 schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:</div><br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 1:10 PM, Andreas Wacknitz <span dir="ltr"><<a href="mailto:a.wacknitz@gmx.de" target="_blank">a.wacknitz@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div style="word-wrap:break-word"><br><div><div>Am 22.04.2014 um 21:36 schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:</div>
<br><blockquote type="cite"><div dir="ltr">Hi Andreas,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 12:05 PM, Andreas Wacknitz <span dir="ltr"><<a href="mailto:a.wacknitz@gmx.de" target="_blank">a.wacknitz@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
This evening I further dealt with the problems on OpenSolaris (openindiana).<br>
I finally got a pthread version running without superuser rights. But I don’t know whether this will really work (ATM it does for me)<br>
because I removed the call to pthread_setschedparam in beatStateMachine leaving the heartbeat thread with the same<br>
priority than the vm thread. </blockquote><div><br></div><div>Alas, that will not work -(. As soon as the image enters into a hard loop (e.g. [true] whileTrue) the heartbeat thread will be blocked and the VM will never break out of the loop.</div>
</div></div></div></blockquote><div><br></div>How can I check this blockage? I started the VM with --pollpipe 1 and then [true] whileTrue in a Workspace. The GUI is blocked but the pipe is still rotating.</div></div></blockquote>
<div><br></div><div>Can you interrupt with ctrl-period? If not, then I don't understand how the pip is still rotating :-). If you can, then you're not blocking the system. Try e.g. [[true] whileTrue] forkAt: Processor highestPriority.</div>
</div></div></div></blockquote>Yes, I can do that in both (with and without higher priority) BUT not when running this with highestPriority (again in BOTH versions!).</div></div></div></blockquote><div><br></div><div>Oops That's right. It should be just "[[true] whileTrue] forkAt: Processor userPriority + 1". Obviously one can't interrupt something running higher than userInterrupt priority. Sorry, I was asleep.</div>
</div></div></div></blockquote></div>See above. OpenSolaris seems to run fine with the two threads having the same priority.</div></div></blockquote><div><br></div><div>Since I've been here before I know that examples can be constructed when this will not work properly. My Delay example above should be one of them. All one needs is to arrange that the system is fully busy, shuts out the heartbeat thread, but depends on the heartbeat thread to make progress (as in the Delay example; the heartbeat advances a low-resolution (~2ms) clock that is used to fire delays).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="">
<blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">You are running the JIT right?<br></div></div></div></blockquote>How to tell for sure? </div></blockquote><div>
<br></div><div>vm -version</div><div><br></div><div>If it includes a CoInterpreter line you're running the JIT. e.g.</div><div><div>McStalker.macbuild$ oscfvm -version</div><div>/Users/eliot/Cog/oscogvm/macbuild/Fast.app/Contents/MacOS/Squeak</div>
<div>4.0 4.0.2894 Mac OS X built on Apr 14 2014 17:02:16 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3) [Production VM]</div><div>CoInterpreter VMMaker.oscog-eem.674 uuid: eefd603d-9638-4ad8-99c0-4ee12e87d49d Apr 14 2014</div>
<div>StackToRegisterMappingCogit VMMaker.oscog-eem.674 uuid: eefd603d-9638-4ad8-99c0-4ee12e87d49d Apr 14 2014</div><div>VM: r2894 <a href="http://www.squeakvm.org/svn/squeak/branches/Cog" target="_blank">http://www.squeakvm.org/svn/squeak/branches/Cog</a> Date: 2014-04-14 15:32:11 -0700</div>
<div>Plugins: r2545 <a href="http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins" target="_blank">http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins</a></div></div><div><br></div></div></div></div></blockquote>
</div><div><div>merkur pharo-without-higher-priority $ ./pharo --version</div><div>3.9-7 #1 22. April 2014 20:30:39 CEST gcc 4.7.3 [Production VM]</div><div>NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Apr 22 2014</div>
<div>NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Apr 22 2014</div><div><a href="https://github.com/pharo-project/pharo-vm.git" target="_blank">https://github.com/pharo-project/pharo-vm.git</a> Commit: 9e648898f53aadb692f2dc95f432daedc449d432 Date: 2014-04-09 16:01:20 +0200 By: Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>> </div>
<div>SunOS merkur 5.11 illumos-b6240e8 i86pc i386 i86pc</div><div>plugin path: /home/andreas/bin/pharo-without-higher-priority/ [default: /home/andreas/bin/pharo-without-higher-priority/]</div><div><br></div></div><div><br>
</div><div>What does this tell?</div></div></div></blockquote><div><br></div><div>That you're using the JIT (NBCogit & NBCoInterpreter).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>I started the VM with —trace. The last log is „IRBytecodeGenerator>>from:goto“.</div><div>The pipe is still rotating but ALT-. does not break the loop (maybe a problem of my Pharo image?; I will try later with a Squeak image).</div>
<div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I tried to replace the pthread_setschedparam call with a similar pthread_setschedprio call but<br>
with no luck (same problem: failed call with "Not owner"). I don’t know wether this is a general problem with the pthreads implementation<br>
on Solaris or just a problem with the gcc version (4.4.4) coming with the openindiana distribution I am using. Maybe this works only<br>
with the compilers and libraries that is delivered by Oracle (Solaris 10 ships with gcc 3.4.3; Solaris Studio has its own compilers).<br></blockquote><div><br></div><div>It's too do with pthreads. Nothing to do with the compiler. On some implementations it requires special permission to create threads with different priorities. That used to be the case on linux and it appears to be the case on OpenSolaris. Hence one is stuck with the itimer heartbeat.</div>
</div></div></div></blockquote>Is there any implementation actually using sqUnixITimerHeartbeat.c? </div></blockquote><div><br></div><div>Yes, but unhappily. We use it at Cadence because we have customers on pre 2.6.12 kernels. We have to e.g. switch off the heartbeast around certain external calls.</div>
</div></div></div></blockquote>I am still wondering about where the necessary sleep call will be generated in this case. I will check your latest VM sources. Maybe PharoVM is different here…</div></div></blockquote>
<div><br></div><div>Where is there a necessary sleep?</div></div></div></div></blockquote></div>My understanding is that the interrupt handler for the heartbeat is waiting for SIGALRM. Typically this is emitted by an expiring usleep or nanosleep call. I cannot see one in the code that is active</div>
<div>when compiling the pharo-vm with ITIMER_HEARTBEAT flag set. In case that VM_TICKER flag is set there is an nanosleep call in the corresponding code.</div></div></blockquote><div><br></div><div>But SIGALRM is also delivered by setitimer, as in</div>
<div><br></div><div>...</div><div># define THE_ITIMER ITIMER_REAL</div><div># define ITIMER_SIGNAL SIGALRM</div><div>...</div><div>if (setitimer(THE_ITIMER, &pulse, &pulse)) {</div><div><br></div><div>in platforms/unix/vm/sqUnixITimerHeartbeat.c. I'm surprised this doesn't work on OpenSolaris. In fact, I can't believe it doesn't work. Something odd must be going on.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br>
</div><div>The fact that my ITIMER_HEARTBEAT version is running when external SIGALRM’s being triggered confirms my view that a source for this signal is missing.</div></div></blockquote><div><br></div><div>We;;, the source is there (the call to setitimer) but for some reason something is going wrong. I suspect the signal handler fires only once. SysV unixes need a signal handler to be rearmed with a call to signal or sigaction in the handler. This is daft, soby default sigaction avoids having to rearm (saving a costly system call on every signal). The old behaviour can be reinstated using SA_RESETHAND. Perhaps on OpenSolaris one has to explicitly use a flag that is the converse of SA_RESETHAND that says "don't reset the handler after delivery".</div>
<div><br></div><div>Here's the relevant excerpt from the Mac OS X manual page for sigaction:</div><div>"SA_RESETHAND If this bit is set, the handler is reset back to SIG_DFL at the moment the signal is delivered."</div>
<div></div></div><div><br></div><div>HTH,</div><span class="HOEnZb"><font color="#888888">-- <br>best,<div>Eliot</div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div>