-
Notifications
You must be signed in to change notification settings - Fork 48
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
Implement sigtimedwait for use by suckless init #1320
base: master
Are you sure you want to change the base?
Conversation
Finished sigtimedwait, but there's a bug, test crashes in some unexpected place.
Finished sigtimedwait, but there's a bug, test crashes in some unexpected place.
@panantoni01 Please extract |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly minor changes or questions, because I am not an expert in signals.
I am also wondering what are the files etc/rc.init
and etc/rc.shutdown
. I think they are not needed by any of changes in this PR.
td->td_flags |= (timeout > 0) ? TDF_SLPTIMED : TDF_SLPINTR; | ||
td->td_flags |= TDF_SLPINTR; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not familiar with sleepq, but was there a reason why we chose TDF_SLPINTR
only when we hadn't got a timeout? You have changed the semantics here and I cant tell if it is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I did change the semantics as I think it was a bug that TDF_SLPINTR
was not set. See discussion here: https://discord.com/channels/951841212267130950/1054133625731424337
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I agree with that, but I also think that @cahirwpz should take a look at that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it has to do with possible deficiencies in sleepq
API. ATM we have two wait
functions - with and without timeout. IMO there should be wait
and wait_intr
with optional timeout. That should let us express all use cases for putting a thread to sleep.
Please note that non-interruptible wait
should probably be only used by the code that does not interface user-space directly - i.e. the code that does not understand the concept of a signal or need not be burdened with complexity of extra error handling (ETIMEDOUT
). Examples would be waking up a thread from interrupt or "fast" device drivers code. On contrary the interruptible wait
should be used in "slow" device drivers code (where read
or write
may be interrupted) and all syscalls that can tolerate being interrupted.
Perhaps what I wrote above should be redacted and put somewhere into sleepq.h
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To answer the question - the change is ok, since function is documented as follows:
/*! \brief Performs interruptible sleep with timeout.
*
* Timed sleep is also interruptible. [...]
*/
bin/utest/signal.c
Outdated
/* ======= signal_sigtimedwait_timeout ======= */ | ||
static int sigusr2_handled = 0; | ||
|
||
void sigtimedwait_timeout_sigusr2_handler(int signo) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't you name it sigusr2_handler
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way I know that some particular test will be the only user of this function.
Suppose someone in the future would like to use the sigusr2 for testing, then they'd need to create a new function, how would they name it then? They could reuse this function, but I advise against that. If one would like to change the behavior of the handler for some particular test they'd need to create a new function and give it some other name anyway.
EDIT: Maybe it's an overkill, I don't know, wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggested it because I see that in other signal tests we name functions that looks like that always in the same way. These functions are used in multiple tests and I think there is nothing wrong in that (they are used identically so why we would like to duplicate code?).
If you would like to add some functionality to such function then it is a reason to make function with unique name (and leave the old one unchanged because we expect some specific behavior from it).
@cahirwpz @pwit81 I think that we can think about making such function a standard. They are used pretty often and maybe we don't have to invent new functions for just handling one signal for every written test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@franciscozdo @korbiniak It's definitely a good idea to factor it out.
I'd do it by extending our current utest.h
interface by adding:
void signal_count(int signo)
- registers a generic handler forsigno
signal,int signal_counter(int signo)
- returns a number of times signalsigno
was delivered.
If you have a better idea how to name those functions then feel free to do so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is a purpose of /etc/rc.init /etc/rc.shutdown? How it is related to sigtimedwait
or /dev/tty
?
@korbiniak I'd like to take over the PR and finish the work. WDYT? |
Implement
sigtimedwait
system call.