let readAndDispatch() handle multiple messages about eclipse.platform.swt HOT 12 CLOSED

I wonder if there is actually a use-case where it is important that only one event is read? If not I think it is fine handle multiple events. EventLoopProgressMonitor even uses 50ms so even 10ms would be fine I think as in most cases there is even not much to do than reading another event from the queue or sleep ...

from eclipse.platform.swt.

I know it is against the javadoc which clearly states readAndDispatch() will "Reads an event " which sounds like single event.

That says it all. Documented shouldn't be changed, and if there is a good reason to challenge them, they should be brought for consideration to PMC with an argumentation.
I think it was already discussed in another issue that some OS might manipulate their event queue while applications are processing. For example we can imagine that if one event causes an operation takes a long time in the SWT UI thread, then further OS events are generated in the meantime, but some of them may be removed/replaced because the OS know some intermediary events are not relevant. I'm not sure it's a realistic case, but theorically, it could be 1 good reason to request OS more often instead of getting a local copy of events.
However one may want to create and use an extra method to allow processing a batch of events.

from eclipse.platform.swt.

That says it all. Documented shouldn't be changed

I think there is still room for interpretation. e.g what is "an event", e.g. if I double click, the OS might or might not generate numerous events, but from an outer perspective I might see this as "one double click event".

I think it was already discussed in another issue that some OS might manipulate their event queue while applications are processing.

As SWT is OS dependent one might still optimize that on OS that do not do this, or check some "no longer relevant" flags.

from eclipse.platform.swt.

As mentioned in #79 (comment) , I also have concerns with such a change which seems quite risky to me. I would like to be proven that the change is either not risky (ie have guarantees that in the end the exact same events are processed if we cache some instead of polling always, ie that we know neither OS nor SWT has smartness to manipulate the event queue while application is processing a former event); or that the value of the change is really huge to make that risk profitable.

from eclipse.platform.swt.

I would like to be proven that the change is either not risky (ie have guarantees that in the end the exact same events are processed if we cache some instead of polling always, ie that we know neither OS nor SWT has smartness to manipulate the event queue while application is processing a former event);

Sure I'm just wondering, if I have a native application how is it handled there? Why is there access to a queue if the queue changes without any notice and I can't use that queue anyways?

So my assumption would be that either it is safe to access the queue in all cases or in no cases the event could otherwise vanish / replace / change while I'm processing it.

from eclipse.platform.swt.

To be precise: the current implementation does not obey the contract in the javadoc - when reading carefully javadoc says: 1 event from OS queue + all internal events

"this method also checks if any inter-thread messages (created by syncExec() or asyncExec()) are waiting to be processed, and if so handles them before returning"

runDeferredEvents() drains the whole eventQueue but runAsyncMessages(false) did not drain the whole Synchronizer.messages filled by asyncExec().

Also it is wrong that runAsyncMessages() is not executed when there was an OS msg. and why is runDeferredEvents() only called when there was a OS message?

I don't want to force to make any change here, but it is not only slow but not conforming to javadoc - but probably always was.

from eclipse.platform.swt.

but not conforming to javadoc

I also think that the javadoc is not that normative (and never can be) as I as the caller (=consumer of the API) can't know much about the internals, and I don't have a real alternative to calling that method, nor do I get any useful feedback (just: probably call me again...) or could influence the call (no parameters), so I really do not care much as long as the right things happen (my UI is responsive).

from eclipse.platform.swt.

By the way as we are talking about the javadoc it says:

@return false if the caller can sleep upon return from this method

in the method doc it says:

and returns true if there is potentially more work to do

strange enough it returns true on linux if the display is disposed... so a simple loop to empty the queue:

while(!Display#readAndDispatch) {
 //we want an empty queue...
}

could loop forever if the display is disposed (can this happen?) while an event is processed.

Edit: Forget about that, it will then throw exception o checkDevice on the next calls...

from eclipse.platform.swt.

could loop forever if the display is disposed (can this happen?) while an event is processed.

Edit: Forget about that, it will then throw exception o checkDevice on the next calls...

but it's not documented to throw exception ;-)

Edit: forget about this - it is documented and thus the implementation on windows is wrong to not throw an exception 😎

from eclipse.platform.swt.

windows is wrong to not throw an exception sunglasses

checkDevice (); is doing that already.

from eclipse.platform.swt.

I've commented already in #80 (comment) :

This is very sensitive area & should be tested on all 3 platforms.
I'm not sure a potential improvement for the synthetic use case of billions async messages is worth introducing a subtle regression.

Running "all" "asyncExec" pending tasks (even time bound) might "ignore" OS events triggered by one of them, so we will see OS native events handled "too late", and see strange effects no one will ever be able to trace to this change.

So unless there is a very good reason to change that, I would leave that "as is".

from eclipse.platform.swt.

Let's keep as-is until we find a need. I'll keep in mind that there is optimization potential for unusual cases.

from eclipse.platform.swt.