Quote:@Ray: Thanks for your fast reply. I am no experienced programmer and my English might be too bad to understand your explanation completely.
So far, I did not check if the @GetFromKeyboard() command influences the speed of other applications running on the client machine. But in my opinion, it is no usual behavor that a software causes 100% CPU load while running a loop waiting for a keystroke.
It isn't entirely typical. It is called a "busy wait". Usually, most programs (including Sesame) use a "sleeping wait" for events. Sesame's main event loop uses a sleeping wait.
Quote:Some time ago, I did some programming in PureBasic and there is a command which returns the control to the operating system for x milliseconds. This command can be integrated into loops to avoid useless high CPU load.
We may well add an optional timeout value to the GetFromKeyboard function, to allow just that. And, to make sure that there is a way out, should the user not ever press a key.
Quote:However, I would appreciate if you would try to explain me why it is neccessary to cause a 100% CPU load just to capture a keystroke.
To allow events (especially screen updates) to still be processed, while the system is also waiting on the user to press a key, Sesame spawns a second event loop that "polls" for events. If the event is the keystroke, the loop is completed. If it isn't the keystroke, the event still needs to be processed, without dropping out of the busy loop. Otherwise, screen updates (for example) would be disabled while the system waits for a keystroke.
That would ordinarily be okay, if one of the internal functions in Sesame (Sesame itself) needed the keystroke. But SBasic functions are called from a callback that is itself called from the main event loop. That means that the way for the non-keystroke event to be sent back to the main event loop to be handled is by calling the main event loop recursively. We could, of course, do that. But SBasic itself is not re-entrant. So, if we were to call the main event loop, there is a high risk that subsequent events could cause another callback to be called, that might in turn, call a different SBasic "event" - causing re-entrancy in SBasic.
So, instead of calling the system event loop, we poll the event queue directly and disable the main event loop temporarily, passing the non-keyboard events to the routines that require them - bypassing the callback mechanism, protecting SBasic from re-entrant conditions. It is the rapid polling of the event queue that pushes the CPU up. Fortunately, because events are I/O bound, the event queue itself forces the process to relinquish the CPU if there is no event, allowing other processes to run nearly as rapidly as ever.
I know that this is probably a more technical explaination than we were hoping for... If Sesame were a general programming environment, like PureBasic, I would agree with you 100%. But, SBasic in Sesame is more a "responsive" environment, completely driven by the events that arrive in the Sesame windows.
In Sesame 1.1.x there is really only one command that directly interfaces directly with the low level (MSWindows or X11) events: @GetFromKeyboard. Sesame 2.0 has a number of commands that allow finer control, including one that passively polls events (completes if there are none), and another that allows an SBasic callback to be invoked based on a low level event's arrival.
Quote:Best regards,
Daniel (from Germany)
Could you possibly use the on immediate change event on a LE instead of @GetFromKeyboard? By reading the value in the LE and then clearing it, you could find out what the user has typed without causing a busy wait. You would probably have to mark the other LEs as "read only" to prevent the user from setting focus in other LEs. But it wouldn't interfere with other events like mouse clicks, etc...
Pages: 1
Send Topic 
Print
100% CPU load while @GetFromKeyboard() waiting (Read 1615 times)
