tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: _SC_SIGQUEUE_MAX
On Jun 22, 1:23pm, charles.cui1984%gmail.com@localhost (Charles Cui) wrote:
-- Subject: Re: _SC_SIGQUEUE_MAX
| Any comments on the tests?
Yes, I am not finished yet testing and looking. Here are some preliminary
ones:
1. You've added more fields to sched_params. This should not be done lightly
because the system call interface is an ABI. If we want to keep them we
should version the syscall. There are more questions about the change.
Is this the right set of fields? How about exposing others like depth?
Should those fields be settable? Do they belong in the sched_params if
they are not? Even if we accept all of that they changes should be
documented...
2. On the unit test itself. It is fine what you did to check if the priority
of the thread was changed after it took the mutex lock. I would have
also written the test like:
create thread 1
make thread 1 low priority
print message with priority info
grab mutex.
print message with priority info
release mutex
print message with priority info
create thread 2
make thread 2 high priority
print message with priority info
attempt to grab same mutex as thread 1
print message with priority info
see that thread 1 runs before thread 2
instead of using thread 1 and main to make things more obvious, but it
is fine.
I am running a system with the patches and testing it... Let's discuss
the sched_params syscall modification... We should also look what other
fields other OS's expose. Once we decide that you can add documentation
and I can start committing the changes.
christos
Home |
Main Index |
Thread Index |
Old Index