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
