Skip to content
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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

grantae
Copy link
Contributor

@grantae grantae commented Sep 9, 2016

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.

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).
@grantae
Copy link
Contributor Author

grantae commented Sep 9, 2016

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.
@grantae
Copy link
Contributor Author

grantae commented Sep 26, 2016

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:

  1. Add multi-context vDSO support to allow signal handlers to call vDSO functions. Currently a vDSO call in a signal handler will corrupt an interrupted vDSO call. (I've implemented this in my own branch).
  2. Add a more general "delayed signal injection" interface to zsim which is mostly decoupled from the scheduler. This interface basically serves to enqueue signals for sys_alarm and sys_setitimer. It would also provide the return information for these calls and sys_getitimer. I've also implemented this, but currently it copies the logic from process_stats to compute process virtual time--at best this is redundant.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant