[Pharo-project] Waste of CPU Power by polling events?

Levente Uzonyi 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 
> things:

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:
> isDraggingEvent
> isDropEvent
> isEditEvent
> isKbdEvent
> isMorphicEvent
> isNoteEvent
> isTempoEvent
> isWindowEvent
>
>
> Hmmm ... quite a lot of events being polled:
>
> Need additional:
>
> isOnMouseOverEvent
> isMouseGestureEvent
> isTouchGestureEvent
> isNetworkEvent
> isUSBEvent
> isSerialEvent
> isParallelPortEvents
> isCtrl-C-Event
> ...
>
> 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 
> event-machines.
>
> 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.


Levente

>
> tnx, regards
>
> Guido Stepken
>
>
>




More information about the Pharo-project mailing list