12:45 a.m.
Hi Marcel.
I have finally got around to do some coding in oFono again,
and have started to look into creating CAIF Network Interface
using RTNL, instead using socket ioctls.
I have started out by doing the RTNL handling async,
i.e. registering the RTNL socket with g_io_add_watch etc.
But I'm not really happy with the code as it feels
unnecessary complex, introduces new states in gprs-context.c. etc.
So I would like to do the RTNL handling synchronous instead,
as this would reduce complexity. But I just wanted your opinion
on this before I start refactoring my code.
Do you see any issues with doing RTNL request synchronous
i.e. sending out RTM_NEWLINK request and a waiting for
RTM_NEWLINK response followed by NLMSG_ERROR,
(or just NLMSG_ERROR if unsuccessful)?
Regards
Sjur
5:46 a.m.
Le dimanche 30 mai 2010 17:45:04 Sjur BRENDELAND, vous avez écrit :
I have started out by doing the RTNL handling async,
i.e. registering the RTNL socket with g_io_add_watch etc.
But I'm not really happy with the code as it feels
unnecessary complex, introduces new states in gprs-context.c. etc.
Using an event loop makes sense if, and only if, the process blocks as far as
poll() is concerned. If your ioctl() calls or Netlink requests do not enter
the kernel scheduler at any point, then the glib main loop will just slows
things down - more code, more context switches.
As an counter example, some people believe so blindly in event loops that they
use them to read *regular* files, and then recommend it to their friends.
Nevermind that POSIX states that regular files are always marked ready for
POLLIN and POLLOUT events, i.e. poll()'ing a regular file will always return
immediately. Thus the event loop is defeated, and just constitutes useless
code complexity and wasted CPU time. (Of course, if the same code path can
cope with non-regular files, then using poll() might make sense, don't make me
say what I did not.)
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
5:58 p.m.
Rémi Denis-Courmont wrote:
> I have started out by doing the RTNL handling async,
> i.e. registering the RTNL socket with g_io_add_watch etc.
> But I'm not really happy with the code as it feels
> unnecessary complex, introduces new states in gprs-context.c. etc.
Using an event loop makes sense if, and only if, the process blocks as
far as poll() is concerned. If your ioctl() calls or Netlink requests
do not enter the kernel scheduler at any point, then the glib main
loop will just slows things down - more code, more context switches.
Thanks Denis,
I think a synchronous implementation should be find then.
If I understand RT-Netlink correctly, creating a CAIF Network Interface should
not enter the poll() or wait in recvmsg. When sending RTNL newlink message,
the whole newlink operation should execute in the senders thread, and
response messages be ready in the rtnl sockets receive queue when the send
operation completes. Hence read/poll should not block the thread.
Regards
/Sjur
4493
days inactive
4494
days old
2 comments
2 participants
participants (2)
-
Rémi Denis-Courmont -
Sjur BRENDELAND