Squeak is doing a *lot* of gettimeofday()

Andreas Raab Andreas.Raab at gmx.de
Tue Feb 12 21:47:21 UTC 2002


I should notice though, that my remarks did _not_ apply to running a
thread as an interpreter-internal timing service. In this case it a)
doesn't matter if your OS supports threads or not (since the
non-threaded behavior is already there) and b) it is in fact faster and
more accurate (well, that's the theory at least - your milage may vary).

All that's really needed to implement something along the lines of
David's design is to add a single call announcing the next wakeup time
to the VM and simply _remove_ the call to ioMSecs from primitive
response (assuming that the timer thread sets the internal interrupt
check flag accordingly when woken up).

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Noel J. Bergman
> Sent: Tuesday, February 12, 2002 10:21 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Squeak is doing a *lot* of gettimeofday()
> 
> 
> > But what about using PTHREAD support instead! Seems a simple choice
> ? for many platforms that have PTHREAD ...
> 
> Funny you should raise this ... I was just asking Andreas, 
> off-list, about
> the lack of true threading in the Squeak VM.
> 
> He felt that:
> 
>       1 threads are just not available on all platforms
> 	  and their semantics differ wildly (look at Java's
>         differences regarding threads across different platforms).
> 
>       2 multi-threading does not give any advantage in speed unless
>         you're running on a multi-processor scheme.
> 
> And apparently, the current VM is not designed to be thread friendly.
> Unlike, for example, some implementation where the 
> Interpreter is a real
> object instantiated for each Process.
> 
> Therefore without some compelling reason, such as performance 
> and override
> the value of portability allowed by Squeak managing it's own "green
> threads", what is the point of restricting the execution 
> model to the native
> thread implementation?
> 
> On the flip side, I'll note that threading reduces polling and better
> supports blocking I/O.
> 
> 	--- Noel
> 
> 





More information about the Squeak-dev mailing list