phobos commit, revision 2107


user: schveiguy

msg:
Fixed static destructor so sockets aren't closed on every thread exit in windows.  (see bug 4344 and 4951)

Fixed unlisted bug, there could be a race condition on linux with gethostbyname and gethostbyaddr, now synchronizing entire processing of hostent struct.

http://www.dsource.org/projects/phobos/changeset/2107

On 10/19/2010 6:15 AM, dsource.org wrote:
> phobos commit, revision 2107
> 
> 
> user: schveiguy
> 
> msg: Fixed static destructor so sockets aren't closed on every thread exit in windows.  (see bug 4344 and 4951)
> 
> Fixed unlisted bug, there could be a race condition on linux with gethostbyname and gethostbyaddr, now synchronizing entire processing of hostent struct.
> 
> http://www.dsource.org/projects/phobos/changeset/2107

There's a thread-safe version of gethostbyname, gethostbyname_r, that you could use to avoid having to syncronize those blocks.  Or even better, migrate to getnameinfo on both linux and windows to move to the modern implementation.

Your change is an improvement from unsafe use of a non-threadsafe api, but..

Later,
Brad

----- Original Message ----

> From: Brad Roberts <braddr at puremagic.com>
> 
> On 10/19/2010 6:15 AM, dsource.org wrote:
> > phobos commit, revision  2107
> > 
> > 
> > user: schveiguy
> > 
> > msg: Fixed  static destructor so sockets aren't closed on every thread exit
>in
> >  windows.  (see bug 4344 and 4951)
> > 
> > Fixed unlisted bug,  there could be a race condition on linux with gethostbyname and  gethostbyaddr, now synchronizing entire processing of hostent  struct.
> > 
> >  http://www.dsource.org/projects/phobos/changeset/2107
> 
> There's a  thread-safe version of gethostbyname, gethostbyname_r, that you
>could
> use to  avoid having to syncronize those blocks.  Or even better, migrate  to getnameinfo on both linux and windows to move to the modern  implementation.

getnameinfo looks like the right path.  I just did what I did because it was braindead simple and I didn't have to expend a lot of effort on it :)  It's just something I noticed when trying to figure out why multithreaded gethostbyname calls were breaking on Windows.

Anyone with MacOSX confirm that getaddrinfo and getnameinfo exist on that OS?

> Your change is an improvement from unsafe use of a  non-threadsafe api,  but..

*shrug* it's better than what was there.  It needs more attention, but I'm not sure if std.socket is going to be replaced or not.

This also doesn't protect against someone calling gethostbyname directly.

-Steve

On 19 okt 2010, at 20:45, Steve Schveighoffer wrote:

> ----- Original Message ----
> 
>> From: Brad Roberts <braddr at puremagic.com>
>> 
>> On 10/19/2010 6:15 AM, dsource.org wrote:
>>> phobos commit, revision  2107
>>> 
>>> 
>>> user: schveiguy
>>> 
>>> msg: Fixed  static destructor so sockets aren't closed on every thread exit
>> in
>>> windows.  (see bug 4344 and 4951)
>>> 
>>> Fixed unlisted bug,  there could be a race condition on linux with gethostbyname and  gethostbyaddr, now synchronizing entire processing of hostent  struct.
>>> 
>>> http://www.dsource.org/projects/phobos/changeset/2107
>> 
>> There's a  thread-safe version of gethostbyname, gethostbyname_r, that you
>> could
>> use to  avoid having to syncronize those blocks.  Or even better, migrate  to
>> getnameinfo on both linux and windows to move to the modern  implementation.
> 
> getnameinfo looks like the right path.  I just did what I did because it was braindead simple and I didn't have to expend a lot of effort on it :)  It's just something I noticed when trying to figure out why multithreaded gethostbyname calls were breaking on Windows.
> 
> Anyone with MacOSX confirm that getaddrinfo and getnameinfo exist on that OS?

They exist.

>> Your change is an improvement from unsafe use of a  non-threadsafe api,  but..
> 
> *shrug* it's better than what was there.  It needs more attention, but I'm not sure if std.socket is going to be replaced or not.
> 
> This also doesn't protect against someone calling gethostbyname directly.
> 
> -Steve
> 
> 
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg