Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #1319 > unrolled thread
| Started by | ittium <ittium@gmail.com> |
|---|---|
| First post | 2011-09-26 10:39 +0530 |
| Last post | 2011-09-26 13:44 -0700 |
| Articles | 4 — 4 participants |
Back to article view | Back to comp.unix.programmer
Non-blocking socket operations ittium <ittium@gmail.com> - 2011-09-26 10:39 +0530
Re: Non-blocking socket operations Nobody <nobody@nowhere.com> - 2011-09-26 13:02 +0100
Re: Non-blocking socket operations Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-09-26 19:10 +0100
Re: Non-blocking socket operations William Ahern <william@wilbur.25thandClement.com> - 2011-09-26 13:44 -0700
| From | ittium <ittium@gmail.com> |
|---|---|
| Date | 2011-09-26 10:39 +0530 |
| Subject | Non-blocking socket operations |
| Message-ID | <j5p1dq$8i9$1@dont-email.me> |
Group, One of my software was running in to performance problems randomly. Debugging of the problem revealed, that blocking socket calls ( blocking the worker thread) were reason for these performance problems. I have recently modified the code so that it now uses the non-blocking operations. Given below are the changes that I have made. connect ------- connect on non-blocking socket may either return immediately or with EINPROGRESS. In the second case we start a timer and on timer expiry, using select, we find out whether connect was successful. fd is marked as connected if - socket fd is writable - writting zero bytes on socket is successful. If not Issue - Is this logic portable. Currently I can test the system on linux only but I would like to keep the system portable. Accept ------ - Accept is attempted on a listening non-blocking socket socket, till you get EAGAIN. Following errors are ignored (ie call accept again) -ECONNABORTED -EPROTO Issue - Is this logic portable. Currently I can test the system on linux only but I would like to keep the system portable. getaddrinfo ----------- getaddrinfo is executed in a thread result is returned in a call back and then this thread exit. Issue- When software is doing lot of DNS lookups, lots of such threads will be needed. Is there a better way of doing it. thanks Ittium
[toc] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-09-26 13:02 +0100 |
| Message-ID | <pan.2011.09.26.12.02.57.380000@nowhere.com> |
| In reply to | #1319 |
On Mon, 26 Sep 2011 10:39:11 +0530, ittium wrote: > getaddrinfo > ----------- > getaddrinfo is executed in a thread result is returned in a call back > and then this thread exit. > > Issue- When software is doing lot of DNS lookups, lots of such threads > will be needed. Is there a better way of doing it. You could use the resolver functions directly, but it's non-trivial to get it right (e.g. re-issuing requests using TCP if a UDP query results in a truncated response), and it will only handle lookups via DNS, not /etc/hosts, NIS, LDAP, etc. On Linux, you can use getaddrinfo_a(), but it isn't portable. If your program is GPL, you can use the GNU adns library.
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-09-26 19:10 +0100 |
| Message-ID | <87bou718fg.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #1319 |
ittium <ittium@gmail.com> writes: [...] > connect > ------- > connect on non-blocking socket may either return immediately or with > EINPROGRESS. In the second case we start a timer and on timer expiry, > using select, we find out whether connect was successful. fd is marked > as connected if > > - socket fd is writable > - writting zero bytes on socket is successful. If not > > Issue - Is this logic portable. According to the current UNIX(*) standard an attempt to write zero bytes 'may detect and return errors'. Using getsockopt querying the option SO_ERROR at level SOL_SOCKET will do so. It is unclear what the purpose of the timer is supposed to be. The networking stack already contains logic for that and just waiting until the socket becomes writable an inspection a possibly available error code should be sufficient. [...] > getaddrinfo > ----------- > getaddrinfo is executed in a thread result is returned in a > call back and then this thread exit. > > Issue- When software is doing lot of DNS lookups, lots of such threads > will be needed. Is there a better way of doing it. The simple way would be to use a fixed number of address lookup threads and some kind of (userspace) queue to distribute lookup requests among them.
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2011-09-26 13:44 -0700 |
| Message-ID | <6q47l8-5fa.ln1@wilbur.25thandClement.com> |
| In reply to | #1319 |
ittium <ittium@gmail.com> wrote: <snip> > getaddrinfo > ----------- > getaddrinfo is executed in a thread result is returned in a call back > and then this thread exit. > Issue- When software is doing lot of DNS lookups, lots of such threads > will be needed. Is there a better way of doing it. I generally don't like pimping my warez, but IMNSHO you might want to try this: http://25thandclement.com/~william/projects/dns.c.html See resolve_addrinfo() at the bottom of the source file for an example of how to use the struct addrinfo-based API. I've used c-ares, ADNS, etc for years. They were all poorly designed, IMHO. They worked sort-of-okay for simple A lookups, but were a PITA for anything more sophisticated. Plus, I hated being forced to use callbacks.
[toc] | [prev] | [standalone]
Back to top | Article view | comp.unix.programmer
csiph-web