thiago at kde.org
Tue Apr 17 13:02:20 PDT 2012
Any reactions to the proposal below?
I'd like to bring it to some kernel developers to have their feedback, but I
don't want to waste their time if we can poke holes with the D-Bus side of it.
On sexta-feira, 13 de abril de 2012 16.55.26, Thiago Macieira wrote:
> So I think that this is a nice exercise to get the brain started, but we'll
> need kernel help. I'd suggest instead:
> - a new system call that returns a priority-inheritance file descriptor
> - said FD is passed in the D-Bus message
> - whenever a thread is polling that FD, its priority is automatically
> inherited by a process holding that FD open -- this includes FDs currently
> queued in a Unix socket buffer
> - if a process has multiple priority FDs open, it gets the highest priority
> among them
> This solves the problems above:
> a) the priority is given by poll / select, so there's no race condition
> b) since the priority is received automatically, there's no priority
> inversion: you have the FD open, you get it
> c) since we're giving the priority by way of the very syscall we use to
> find out if there's more data on the socket, the sender can be woken up by
> socket data and process it (except if you've given an RT FIFO priority
> d) since the priority is given when the calling thread goes to sleep, by
> consequence it's not running; if it does wake up, the given priority is
> taken away
> Additional benefits:
> e) if the call timed out, the calling thread resumes execution and takes
> away its priority
> f) the daemon code and the library actually need no modification to receive
> priorities: since they receive all file descriptors and keep them open for
> the duration of the DBusMessage, they have the priority.
> However, the daemon code should be modified so it does *not* forward the
> priority FD to eavesdropping receivers. In fact, it should *only* forward to
> the intended receiver, which also neatly solves the issue of priority FDs
> being passed in signal messages: the bus gets the priority, but doesn't
> pass it along
> g) user code often keeps the original DBusMessage around before sending its
> reply, if nothing else for the serial ID. Code that drops the message
> should be adapted to keep it around or at least keep the priority FD. The
> priority FD should be sent along the reply, so the bus daemon gets the
> priority needed to process it.
> h) since a thread gets the highest priority from the priority FDs it has
> open, the bus daemon is automatically running at the highest priority of its
> pending messages, and so are target processes
> priority is usually given per thread, but a file description is a process
> thing. Which thread gets the enhanced priority? All of them?
> What do you think?
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus