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