-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add virtualization for the alarm system call #133
base: master
Are you sure you want to change the base?
Conversation
version of assert() doesn't create any macro redefinitions. This error can appear, for example, if any system or startup files are brought in during compilation and happen to include <assert.h>.
…ed int since the former may be out of range of the latter.
This enables using alarm() to properly receive a signal after the requested amount of virtual time has passed. A new signal queue is added to the scheduler to support this. From a performance perspective this change should be minimal, however it does require checking a queue for emptiness at each phase. Tested with a simple signal-receiving app and pin 2.14 (71313).
Another (possibly better) alternative is to use the event queue for signal delivery, since it's already being called each phase tick. This may also facilitate interval timers (getitimer() etc.) decently well. Edit: At second glance, the current event queue concerns itself with periodic simulator events outside of the scheduler, so maybe an event queue inside the scheduler would be cleaner. |
This allows multiple processes to be able to use delayed signals.
Since submitting this PR I've done more work with timing system calls and general signal support. If it is beneficial to zsim to support these, I think there is a better integration path:
Let me know if you have thoughts regarding this or signal support in general. There are several comments about Pin and signals in the source, but by my understanding it seems this should be doable. |
See the commit log for details. This is only one possible implementation. I'm very open to suggestions/improvements/rewrites.
Note that this PR is dependent on #131 which is currently still pending.