Interrupts and callbacks.
Author
I'm writing an input API where it is possible for a user to specify a callback function for specific events. Some events might be generated by interrupts.
Is it a problem if the user decides to perform a very time consuming operation (maybe many seconds long) inside the callback, and it was generated from an interrupt?
I know that some old machines required interrupt callbacks to be small because no other interrupts could get through.
Thanks
Simon
Author
Also, is it ok to use concurrency objects inside interrupts, eg opening mutexes?
Thanks
Simon
Thanks
Simon
I have two possible solutions:
1: Explain to your user that the callbacks have to be short. I know this sounds lame, but if they are that close to the metal, they need to understand the limitations.
2: Put all events into an event queue, much like any GUI system uses for messages. The user or your library can pull the events off in a separate thread and pass them to the user. Since this is happening outside the interrupt code and in a separate thread, the user can take all the time he/she likes.
1: Explain to your user that the callbacks have to be short. I know this sounds lame, but if they are that close to the metal, they need to understand the limitations.
2: Put all events into an event queue, much like any GUI system uses for messages. The user or your library can pull the events off in a separate thread and pass them to the user. Since this is happening outside the interrupt code and in a separate thread, the user can take all the time he/she likes.
Author
Ok, so it is an issue then, is it.
I have the queue system already, as an option, but the interrupt system is there just in case the user can benefit faster response time, such as a game sending "fire weapon" commands to the server without having to wait for the next input cycle, reducing shooting latency (ping) by an average of "seconds per input cycle / 2", which is not insignificant.
I'm not too fond of relying on the user making the interrupt code short. It's just not clean enough for my API. But if that's the best option, then so be it.
Would it be possible to have something like a waiting list of threads that could be activated by the interrupt which then immediately exits? Would this incur much of a speed / latency penalty?
I have the queue system already, as an option, but the interrupt system is there just in case the user can benefit faster response time, such as a game sending "fire weapon" commands to the server without having to wait for the next input cycle, reducing shooting latency (ping) by an average of "seconds per input cycle / 2", which is not insignificant.
I'm not too fond of relying on the user making the interrupt code short. It's just not clean enough for my API. But if that's the best option, then so be it.
Would it be possible to have something like a waiting list of threads that could be activated by the interrupt which then immediately exits? Would this incur much of a speed / latency penalty?
The message queue could be handled by a separate thread, which would get the messages handled before the normal input cycle.
Also, the messages could be put into the queue with a priority. So messages, like your Fire Weapon example, would be placed at the head of the queue and processed sooner.
Also, the messages could be put into the queue with a priority. So messages, like your Fire Weapon example, would be placed at the head of the queue and processed sooner.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement