Hi,
On 06/26/2014 12:39 PM, microcai wrote:
2014-06-25 18:30 GMT+08:00 Kay Sievers <[email protected]>:
On Wed, Jun 25, 2014 at 11:13 AM, AKASHI Takahiro
<[email protected]> wrote:
In the current implementation, ioctl(CMD_MSG_RECV) returns immediately if
no message has been queued, and so a service process has to wait by
explicitly calling poll() system call. If such a process needs to wait only
on a single connection, we can eliminate poll() system call by adding a
synchronous attribute in receiving a message.
Why is this useful in general? The peer can call RECV in a loop until
EAGAIN without ever needing to call poll() as long as data is
available.
When there is no more message to handle, poll() is used to suspend the
process, and only when it is idle anyway.
One of my ideas behind this hack is Binder's BINDER_WRITE_READ ioctl, which
is kinda combination of write(), poll() and read() in a single system call.
Obviously I don't want to implement such a function into KDbus, but apart from
Binder, "blocking until some messages arrive" is an commonly-seen attribute in
linux as well as other OSs.
One of well-known API's is recv() system call for socket interface.
If we don't have to wait on several end points, its the easiest way of
programing
to catch incoming messages/data.
Busy processes, the use-case we would optimize for, should not see a
real benefit here?
So we can, at least, eliminate "one system call" overhead of poll().
I know that the improvement can be a bit smaller, on powerful processors,
than other hacks.
And library can simulate the sync calls by revc + poll anyway.
There is no real benefit.
Again, I'm not talking about functionality, but performance (or reducing
overhead).
Thanks,
-Takahiro AKASHI
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
