Re: [PATCH BlueZ] shared/io-ell: Add support for ELL based IO handling

Hi Luiz,

quoted

I would rather not do that actually.  It is already weird that you guys have
io_send but not io_recv.  And since io is not only used with streams /
files, but with datagram sockets as well, we would have to add a bunch of
methods for symmetry.  Not to mention that somehow 'send' uses iovecs and
the convention inside ell for this is to suffix the method with a 'v'.

Ive thought of adding io_recv, it just that it was not necessary by
anyone currently, anyway I guess having _v alternative makes ell play
nice if the application is using iovec, or you are saying that with
ell the application would have to use the fd directly and handle
errors?

Right, that's the intent of the ell api.  We only handle the mainloop 
integration with io.  The actual send/recv/write/read/etc should be 
handled outside l_io to keep the l_io API minimal.  There are too many 
variations between socket types, streams, etc.  Most of our projects 
bypassed the weird GLib I/O functions (with its buffering semantics, 
etc) and just invoked the system calls directly anyway.

quoted

By the way, correct me if I'm wrong, but I think there is zero need for
TEMP_FAILURE_RETRY inside BlueZ since it uses signalfd and non-blocking IO
anyway.  The only reason ell uses this macro is because we can't assume how
signals are used in the enclosing application.

Usually, BlueZ tools would use signalfd, including the daemon, we
could perhaps remove the handling of EINTR if we could detect if
signalfd is in fact being used but I don't know if that is possible,
so better be save than sorry.

So I personally wouldn't introduce quasi-ell API that is not mirrored 
inside ell proper.  That will just make your job harder in the future. 
And if the caller of io_send just handles the writev invocation you can 
know exactly if TEMP_FAILURE_RETRY is needed or not.

Ideally this file should not exist.  You might get away with just 
(struct l_io *) io or vice-versa.

Regards,
-Denis