[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #7017] Implement DNS client

From: Frédéric Bernon
Subject: [lwip-devel] [task #7017] Implement DNS client
Date: Thu, 15 Nov 2007 09:04:15 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: Gecko/20071025 Firefox/

Follow-up Comment #29, task #7017 (project lwip):

>Unfortunately per-thread info isn't really sensible here - it is not just
the struct hostent that needs to be per-thread, but the contents of all the
pointers it points to. 

Yes, my own DNS client (socket based) need 5 fields per thread (hostent,
h_name, h_aliases, h_addr_list + addr) to do a clean job.

>This constraint (not being thread-safe) of gethostbyname is widely known and
any existing code should already be aware of it. People writing new code for
lwIP should read some documentation so they know it isn't thread-safe :-). 

Yes, this "socket" function design is not very good (like some old
functions). One of good point is we can add this feature to netconn wihtout
such problem (always under LWIP_DNS=1, of course). I think that such problem
(thread-safe) should be a port problem (like sys_timeouts). I understand that
some ports can be happy with just a simple static "set" of variables, but I
think we can provide a cleaner solution using macros for both cases. I will
thought about that and I'll propose something...

>Some implementations provide an alternative gethostbyname_r function, e.g.
from glibc

Yes, I have the same kind of interfaces on some stack

>I'm undecided on that personally, but I think this should not hold up 1.3. 

No, you're right, it shouldn't. But I will continue to work on that
(sequential api, and "todo list"): if it's good before 1.3.0, I will check in,
else, of course, it will wait the next release...


Reply to this item at:


  Message posté via/par Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]