<div dir="ltr">I did look at using pthread_delay_np to delay the heartbeat thread as my thought was if the image is sleeping why wake up to service the clock, etc. <div>Difficult to measure the outcome, but one should consider that option too. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 12, 2015 at 10:55 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"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 12, 2015 at 10:45 AM, John McIntosh <span dir="ltr"><<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Craig so how does using <span style="font-size:13px">pthread_cond_timedwait affect socket processing? The promise of </span>nanosleep was to wake up if an interrupt arrived say on a socket (Mind I never actually confirmed this the case, complete hearsay...) </div></blockquote><div><br></div><div>+1. What he said. The problem with pthread_cond_timed_wait, or any other merely delaying call is that, unless all file descriptors have been set up to send signals on read/writability and unless the blocking call is interruptible, the call may block for as long as it is asked, not until that or the read/writeability of the file descriptor.</div><div><br></div><div>IMO a better solution here is to a) use epoll or its equivalent kqueue; these are like select but the state of which selectors to examine is kept in kernel space, so the set-up overhead is vastly reduced, and b) wait for no longer than the next scheduled delay if one is in progres.</div><div><br></div><div><br></div><div>Of course, the VM can do both of these things, and then there's no need for a background process at all. Instead, when the V< scheduler finds there's nothing to run it calls epoll or kqueue with either an infinite timeout (if no delay is in progress) or the time until the next delay expiration.</div><div><br></div><div>Now, if only there was more time ;-)</div><div><br></div><div>It strikes me that the VM can have a flag that makes it behave like this so that e.g. some time in the Spur release cycle we can set the flag, nuke the background process and get on with our lives.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 12, 2015 at 2:40 AM, Craig Latta <span dir="ltr"><<a href="mailto:craig@netjam.org" target="_blank">craig@netjam.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Hoi Norbert--<br>
<br>
In 2003, while implementing remote messaging for what became the<br>
Naiad distributed module system[1], I noticed excessive CPU usage during<br>
idle by Squeak on MacOSX (and extremely poor remote messaging<br>
performance). I prepared alternate versions of<br>
ioRelinquishProcessorForMicroseconds, comparing:<br>
<br>
- select() (AKA aioSleepForUsecs in Ian's aio API, my starting point)<br>
- pthread_cond_timedwait()<br>
- nanosleep()<br>
<br>
pthread_cond_timedwait was the clear winner at the time. I wrote my<br>
own relinquish primitive as part of the Flow external streaming<br>
plugin[2], and I've been using it ever since. Still seems fine. I've<br>
mentioned this before.<br>
<br>
<br>
thanks,<br>
<br>
-C<br>
<br>
[1] <a href="http://netjam.org/naiad" target="_blank">http://netjam.org/naiad</a><br>
[1] <a href="http://netjam.org/flow" target="_blank">http://netjam.org/flow</a><br>
<br>
--<br>
Craig Latta<br>
<a href="http://netjam.org" target="_blank">netjam.org</a><br>
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177" target="_blank">+31 6 2757 7177</a> (SMS ok)<br>
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547" target="_blank">+ 1 415 287 3547</a> (no SMS)<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">===========================================================================<br>John M. McIntosh <<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>> <a href="https://www.linkedin.com/in/smalltalk" target="_blank">https://www.linkedin.com/in/smalltalk</a><br>===========================================================================<br></div></div>
</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>best,<div>Eliot</div></div>
</div></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">===========================================================================<br>John M. McIntosh <<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>> <a href="https://www.linkedin.com/in/smalltalk" target="_blank">https://www.linkedin.com/in/smalltalk</a><br>===========================================================================<br></div></div>
</div>