|
|
Hello everyone,
I would like to talk a bit about the way OSWindow makes events available for the user. Currently, a dedicated process with a priority of 60 gets SDL events, converts them into OSWindow events and then makes them available to the user via the OSWindowEventVisitor. Now my concern is that, by default, it is this same process that executes actions specified by the user. (Actually every event is forked to be executed in its own thread but with the same priority of 60 so as Pharo scheduler is not pre emptive it does not change the execution order) So basically, all the operations made in the main thread will be interrupted by the operations made in the event thread since the event thread has a higher priority. I get that it makes the window more responsive since its events are treated almost immediately but if you are not aware of what you are doing you can have some weird behaviors as in every multi-threaded program. It means that if I am a simple user and I want to use OSWindow simply, by default I need to deal with 2 processes and to handle some kind of concurrency even if my application is very simple. I find it a bit harsh. Shouldn't we provide the user with something simple and "unbreakable" by default but let him the possibility to do whatever he wants with extra work instead of providing him with something a bit more advanced by default but that needs extra work to make simple ? Maybe we could provide something a bit like SDL does. Put OSWindow events in a queue and then create mechanisms arround to manage this queue and let the user easily get events he wants. By default any application would be mono-processed but nothing would prevent the user to create a new process dedicated to event handling. What are your thoughts about all that ?
Thanks, Matthieu
|
Locked
