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 > >
