I can see the usefulness of specifying the cpu partition on a pulse send.

It would have to be an explicit paramater to send_pulse, like the current
priority paramater. That's because receiving a pulse does no inheritance
(priority inheritance or otherwise) from the sender.

However, it would become a security hole. Because nothing would prevent a
sender from specifying a partition that they were not a member of. So this
mechanism would effectively allow any thread to run in any partition
regardles of the APS security settings. So it would probably be unworkable,
unless we limited it's use to the root user.

We did think about it years ago and decided not to.

The biggest problem is that increasing the payload of the pulse, in order to
carry a partition field, may be a major kernel change and may even have
performace implications. So we would not undertake it lightly.

-ad

Xiaodan Tang wrote:
> The Pulse will not carry partition info over, this is documented. 
> However, I have real life situations like this.
> 
> The system have 2 partition, say System 70 and Media 30. All system 
> services is run in System partition.
> 
> In Media, there is a low priority (4) thread want to read files, it 
> talks to devb-eide in system partition. This brought a thread in 
> devb-eide down to 4, but that's okay, becuse this thread is now belongs 
> to Media partition.
> 
> The problem happens that sometime, the pri 4 devb-eide will sent a pulse 
> to another thread in devb-eide, ans cond_wait() until the other thread 
> finished it's work.
> 
> This "other thread" in devb-eide now set at pri 4, but belongs to 
> "System" partition. So if other high priority thread in System partition 
> started to run, it will starve the devb-eide pri 4 thread. To make 
> things worse, since Media partition is not using CPU, the high priority 
> thread in System partition would run 100%
> 
> Use a pulse to wake up another thread in server to do some more service 
> is quite normal. This makes a partitioned system do not working as
expected.
> 
> I have then tried to create a 3rd "common resource" partition, moved 
> devb-eide into it. This make the starving harder to happen, but 
> therotically, there is still someone else can talk to devb-eide in high 
> priority, causing a high priroity pulse being sent, and then starve the 
> low priority thread...
> 
> Since "pulse" an carry priority (set by user), I think it is reasonable 
> to allow user set "partitiion" in pulse and carry it over.
> 
> Any thoughts on this in 6.4?
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post6476
>