Il 15/01/2014 19.43, Igor Stasenko ha scritto:
On 15 January 2014 17:58, paolo.bernardi...@gmail.com <mailto:paolo.bernardi...@gmail.com> <paolo.bernardi...@gmail.com <mailto:paolo.bernardi...@gmail.com>> wrote:Il 13/01/2014 2.25, Igor Stasenko ha scritto: On 13 January 2014 00:08, paolo.bernardi...@gmail.com <mailto:paolo.bernardi...@gmail.com> <mailto:paolo.bernardi...@gmail.com <mailto:paolo.bernardi...@gmail.com>> <paolo.bernardi...@gmail.com <mailto:paolo.bernardi...@gmail.com> <mailto:paolo.bernardi...@gmail.com <mailto:paolo.bernardi...@gmail.com>>> wrote: Il 12/01/2014 19.41, Igor Stasenko ha scritto: All i can say that callbacks for handling window events need special handling: - you basically should prevent VM to do event handling during handling of event by callback. Do I achieve that when starting in headless mode? (no ui, no messages...) nope. VM will still run event loop (in ioProcessEvents) and do more or less the same things. that is another reason, btw to bring event loop handling to image level.-- Best regards,Igor Stasenko. Could I prevent VM (as you say, Igor) do process events using primitiveEventProcessingControl? I tried hacking NBFFICallback >> pvtEnter:stackPointer:primitiveMethod: by disabling events before block execution and enabling them after callback termination. Pharo still works for a while, then crashes. nice try.. now i am out of ideas why else it would be crashing :) -- Best regards, Igor Stasenko.
maybe primitiveEventProcessingControl still could be the solution, vm should be already blinded (event processing disabled) when the cb is fired. My nice :) try, instead, just tried to blind vm when cb was already fired. Now I should try to blind vm _before_ any cb is fired. But I'm not sure wxWidgets has chances to ear (and processing) incoming OS events when the vm's thread is freezed.
