John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> >Spot on.  It would be wonderful if someone put in all the checks for
> >EINTR so that this could be enabled more often.  There's no reason for
> >this primitive to be so expensive.
> >
> >.
> 
> But what about using PTHREAD support instead! Seems a simple choice 
> for many platforms that have PTHREAD, or maybe I should ask which 
> (mainstream) U**X wouldn't support it to justify the 
> coding/validation of all these EINTR checks.

Pthreads could also be used, with similar results.  Nevertheless:

- The EINTR checks should be there anyway.  This is just proper Unix
programming.  For a real-world example, suspending with ^Z and then
resuming will also cause EINTR's to happen.

- The itimers version can be adapted to alarm() on Unices that don't
have itimers.  *Every* Unix has alarm(), and so the general solution of
getting a periodic signal will cover all Unices.

- The basic itimers version is implemented already.

The EINTR hacking is probably just a 1-2 hour job.  Adding an alarm()
fallback is half an hour, and setting up the configuration files to
choose between itimers and alarm is probably 1-1.5 hours more.  Overall,
this is not a huge deal, but I've personally never cared enough about
Squeak's speed to spend even this much time on it.



Scott Crosby wrote:
> The variable read may, but the function call overhead doesn't.. Yes, it
> makes it about 10x cheaper. But the correct solution is to *not* read the
> clock 40,000 times a second. Andreas Raab's patch (which I referenced)
> reduces this. If you don't read it 40,000 times a second, you're not
> invoking 40,000 or more functions/second, and its going to be better.

It's probably more than 10x faster -- on x86, a system call is on the
order of 1000 cycles!  Also, it doesn't have to be a real function call
-- it can be a macro, and thus turn into a simple read from a global
variable.


Anyway, sure, both patches sound useful.  There's no need to check the
time on ultra-fast primitives, and some platforms won't be able to
implement such a speedy time check, anyway.  


-Lex