开发者

So setsockopt for timeouts on AF_UNIX (AF_LOCAL) sockets... undocumented/don't work... options/alternatives?

开发者 https://www.devze.com 2023-01-07 09:41 出处:网络
I\'m running Fedora 13 if that matters. I looked up man pages on unix(7), setsockopt, and send/recv. Reading the man pages seems to more or less tell me that not all options are guaranteed to do ANY

I'm running Fedora 13 if that matters.

I looked up man pages on unix(7), setsockopt, and send/recv.

Reading the man pages seems to more or less tell me that not all options are guaranteed to do ANYTHING... and apparently only a few that do/don't work are actually documented.

In particular... I wanted to see if timeouts were 开发者_开发技巧possible. At least on my system, SO_RCVTIMEO actually sets a timout for the recv family of calls... but SO_SNDTIMEO puts the socket seems to set it to non-blocking mode w/ no timeout.

So my question is... what can I do to workaround the fact that setsockopt isn't a reliable way to work with timeouts on AF_UNIX sockets?


Hmm, how about select(2) or poll(2) or epoll(4) with a timeout?


what can I do to workaround the fact that setsockopt isn't a reliable way to work with timeouts on AF_UNIX sockets?

Well, don't use them.

I used epoll(4) in G-WAN (a Web App. Server) and had to face the same issue.

There are basically three ways to handle time-outs:

  1. timers (if you don't care about interrupting your code like a fool)
  2. polling (a dedicated thread with a loop to check fds, takes time)
  3. time-outs (like epoll_wait() with a time-out value, slows-down all)

Some use pipes to wake-up the fds you want to act on. My tests have shown that it is a tremendous waste of resources. Whatever you do, this will be either inefficient or tricky. Sometimes, both (thanks to idiotic kernel developers).

Good luck.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号