Queueing System Expansion:#277
Conversation
PoseidonsCave
commented
Mar 25, 2026
- Added CommandQueue class to manage command execution order and timing.
- Updated CommandManager to utilize CommandQueue for better command handling.
- Modified DiscordBot to integrate with CommandQueue for improved performance.
- Enhanced CommandAction to support queued command execution.
- Added CommandQueueTest to ensure proper functionality of the CommandQueue system.
* Added CommandQueue class to manage command execution order and timing. * Updated CommandManager to utilize CommandQueue for better command handling. * Modified DiscordBot to integrate with CommandQueue for improved performance. * Enhanced CommandAction to support queued command execution. * Added CommandQueueTest to ensure proper functionality of the CommandQueue system.
|
not clear to me what problem you are trying to solve but i have the feeling this is overcomplicated |
|
Basically trying to solve the problem of multiple discord commands being entered at once. The idea is to create a pipeline for if two or more commands are entered simultaneously (whether they are part of a core zenith function, or if the command is for an external plugin. That way it can be managed w/ grace rather than the command being dropped |
|
the command executor can be made single threaded here: just add the queue then is implicit as other threads will have to wait until freed |
|
i mean yeah, but if f multiple plugins can issue commands concurrently, then without a central mechanism, plugin behavior becomes timing-dependent. a plugin issuing commands rapidly could potentially starve or interleave commands from another plugin. A queue provides a fair and deterministic dispatch point between plugins and command execution. e.g if someone is making a pearl request + then initiating an autotrader command |
|
locking is a central mechanism. same as your queue. both are queues actually. and the issues you are bringing up simply don't happen in actual use there's no reason for plugins or anyone else to submit enough commands per second. real use timescales are far larger than you are imagining |
|
ah I see, makes sense, i'll have to mess around with it more. thank you! |