On Mon, 30 May 2016, Stephens, Allan wrote:
Another thought occurred to me over the weekend. See [AL] below.
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: May-26-16 4:11 PM
To: Kumar Gala
Subject: [devel] Re: RFC: Unified kernel
APIs needing special care[AL] Do we really need a fiber for this API? It seems we could get the same effect by temporarily "boosting" the priority of the invoking task to a negative value, calling the desired function, and then restoring the priority level to its original value. This would avoid the overhead of a double context switch, while still ensuring that the function isn't pre-empted by any task-type processing.
Some APIs need special treatment to make them function as they currently
Offload to fiber
Of course, a fiber is needed for this API. It is built on top of the
work_queue library. The system workqueue must be enabled.
In essence, this API could be replaced by the sequence:
orig = task_priority_get();
This being said, there is a potential issue if the function being invoked has the side effect of altering the priority of the invoking task (either explicitly or implicitly). If so, we would have to do something clever to ensure that things don't get messed up -- perhaps taking a similar approach to the one taken to handle priority inheritance with mutexes.
Boosting priority of the invoking task may not be what we want to achieve.
In case of work_queue (correct me if I am wrong) we have an interrupt
handler that offloads the long work to the fiber for instance, taking data
from a temporary buffer and form a packet or so.