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

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Nov 24 14:35:39 CET 2010


what I can tell you is that Pharo got some work to got forward on event and avoid polling but it was
not fully finished. We will continue to work on that in the near future.

On Nov 22, 2010, at 10:08 PM, Guido Stepken wrote:

> I am just porting squeak/Etoys to Samsung-PAD and i noticed some strange things:
> 
> 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?
> 
> 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 ...
> 
> tnx, regards
> 
> Guido Stepken
> 
> 





More information about the Pharo-project mailing list