[Pharo-project] Waste of CPU Power by polling events?
leves at elte.hu
Tue Nov 23 08:58:06 CET 2010
On Mon, 22 Nov 2010, Guido Stepken wrote:
> I am just porting squeak/Etoys to Samsung-PAD and i noticed some strange
Are you porting Etoys to Pharo?
> In Pharo 1.1 network connections seemed to be limited to 4 connections:
> In the listenLoop backlogSize is set to 4. Means - Pharo is limited to max.
> of four simultaneous TCP Connections?
No. You're talking about ConnectionQueue which uses 4 as the size of the
backlog queue. It means that at most 4 unaccepted connection attemts will
allowed to wait, the rest will be rejected. This doesn't limit the number
of accepted connections.
> But: Some MacIntel VM seem to run Squeak with additional worker thread for
> event processing. Maybe this limitation may not occur here?
> Carbon ports of Pharo use ioPeekKeystroke, ioGetKeystroke, ioMousePoint,
> ioGetButtonState instead of
> kEventRawKeyModifiersChanged and kEventMouseMoved event
> Found in Pharo so far:
> Hmmm ... quite a lot of events being polled:
> Need additional:
> I fear, that this costs a lot of wasted VM Power by polling. UNIX, especially
> Linux is changing towards a event machine, driven by interrupts. So -
> Interpreters should also migrated from polling to interrupt driven
> I am missing that in Pharo. Pharo still has too much polling code/algorithm
> running, that slows down Pharo/Squeak/Etoys ... unneccessarily.
> Any ideas appreciated ...
There are two classes for input event handling in Pharo 1.1:
InputEventFetcher and InputEventPollingFetcher. You should be safe to use
InputEventFetcher (which doesn't poll for events) on non-windows VMs, but
the default is InputEventPollingFetcher.
> tnx, regards
> Guido Stepken
More information about the Pharo-project