os.eventCount -- The number of events in the queue

In short, a function that states how many messages are actually waiting in the event queue.
It would greatly help with event management and keeping the flow of programs.

The current way things are, if there are no items in the event queue and a program yields, it sits there waiting for input.
If a program (or thread) is supposed to be handling an automated task and something such as this comes around, the program could end up stuck without input.
The two usual solutions to this are to queue an empty event or queue a timer. Each of these methods have problems however:
Firstly, the empty event is an easy way to clog up the system. Whilst queueing an empty to ensure an instant return from yield can manage a lot of issues, it creates the new issue of clogging up the event queue with empty messages, one for every actual event that comes in.
The issue with the timer method is that it forces the program to handle multiple events at once, and if some of those events happen to be ones it doesn't handle, the program must then re-queue the events in the same order they arrived, which can be awkward if more events are added after the timer fires or if the event the program wants is right near the end.

Adding the ability to check how many events are in the queue or similar pre-emptive functions would make event handling much easier and could enhance the current methods of event handling to make programs run much more smoothly and make event handling systems much less clunky and verbose.

For example if a program wants to check for events but ensure continuous execution (ie not having to explicitly wait for input), it could simply check if events are in the queue, if there are it handles them, but if not it uses the empty event trick to force its continued execution. The resultant code compared to current systems would be much more condensed and prevent issues such as flow interrupt and clogging up the event queue. Furthermore, if the event queue system is implemented using an actual queue, it should just be a matter of setting up a function to return the queue's size.

An alternative would be the ability to peek the queue, which would achieve a similar effect. Again, assuming event queues are implemented using actual Java queues, they should natively support both size checking and peeking.

What is your program supposed to do?

If your program is written like that, you're causing lag. Don't do it. Your program should be designed so that it waits for an event, reacts to it quickly, then goes back to waiting.

immibis, on 04 July 2013 - 02:23 AM said:

What is your program supposed to do?

If your program is written like that, you're causing lag. Don't do it. Your program should be designed so that it waits for an event, reacts to it quickly, then goes back to waiting.

"a program" ie a hypothetical program.

The point is that there are systems where you don't want to be waiting for an event indefinitely.
For example a system where there are two threads/programs, one waiting to handle the possibility of input (ie a UI), one performing some background task such as updating an animation or controlling redstone output. If there's no player around, the input handling system isn't going to have any events to process, but the background task needs to continue. The common way this would be handled is by queueing timers, but in the case that there was a player giving input and it wasn't just the background task at work, the problem is going to arise that the background task will start pulling events intended for the UI and having to put them back up, during which time another event might be added, causing the new event to appear before the older ones. For example the player is writing a command like 'stop' and the reshuffling results in the player's keystrokes being interpreted as 'psto' because control shifts to the background task after the player presses the o key.

Doesn't the parallel API allow you to wait for an event on one function while continuing execution of the other? I know that not everyone likes the parallel API, but you can use coroutines directly if you want.

For a program that updates redstone or monitor output, it's going to need to use timers anyway to avoid spamming outputs. So this isn't even a possible concern for those sorts of things as far as I can tell. Just pull events in a loop that can handle whatever kind of event arrives.

The thing is, events should only ever be "waiting" in the queue when your computer was yielding to other computers (you can write a program so it doesn't yield or pull events for a while, but you really shouldn't, it will "cause lag", as immibis so mildly put it).

This is asking for a solution to a problem that nobody has.

Locked.

LOL NO