Greetings,
After quite an exhausting night (of all the ways I didn't want to spend my
Sunday...) I've managed to track down a problem that has been frustrating me
all night. The problem exists with multiple threads calling gethostbyaddr()
(not necessarily at the same time).
Here's a debug out
Greetings,
After quite an exhausting night (of all the ways I didn't want to spend my
Sunday...) I've managed to track down a problem that has been frustrating me
all night. The problem exists with multiple threads calling gethostbyaddr()
(not necessarily at the same time).
Here's a debug ou
Dan Moschuk wrote:
>
>After quite an exhausting night (of all the ways I didn't want to spend my
>Sunday...) I've managed to track down a problem that has been frustrating me
>all night. The problem exists with multiple threads calling gethostbyaddr()
>(not necessarily at the same time).
src/l
| >After quite an exhausting night (of all the ways I didn't want to spend my
| >Sunday...) I've managed to track down a problem that has been frustrating me
| >all night. The problem exists with multiple threads calling gethostbyaddr()
| >(not necessarily at the same time).
|
| src/lib/libc/n
Dan Moschuk wrote:
>
> | >After quite an exhausting night (of all the ways I didn't want to spend my
> | >Sunday...) I've managed to track down a problem that has been frustrating
> me
> | >all night. The problem exists with multiple threads calling
> gethostbyaddr()
> | >(not necessarily at th
[snip]
gethostbyaddr... actually, most of the gethostby* functions... are not
thread safe. They all use a static buffer in the library.
Therefore, with threads, if you don't take precautions, I'd expect your
results to be odd.
-Brian
To Unsubscribe: send mail to majord...@freebsd.org
wi
---Brian McGovern said:
> [snip]
>
> gethostbyaddr... actually, most of the gethostby* functions... are not
> thread safe. They all use a static buffer in the library.
>
> Therefore, with threads, if you don't take precautions, I'd expect your
> results to be odd.
> -Brian
>
Couldn't this be
...@cisco.com
CC: d...@trinsec.com, hack...@freebsd.org
Subject: Re: gethostbyaddr() and threads.
Date: Mon, 9 Aug 1999 14:21:38 -0700 (PDT)
MIME-Version: 1.0
From owner-freebsd-hack...@freebsd.org Mon Aug 9 14:22:43 1999
Received: by hub.freebsd.org (Postfix, from userid 538)id 13F1E152DC; Mon,
9
---Steve Tarkalson said:
> this is solved by one of two methods:
>1-) require the caller of gethostbyaddr() to supply a pointer to
>a hostent struct which will be filled.
> or 2-) the library uses thread specific storage which is re-used in
>each call.
>
You could malloc() a st
> ---Steve Tarkalson said:
> > this is solved by one of two methods:
> >1-) require the caller of gethostbyaddr() to supply a pointer to
> >a hostent struct which will be filled.
> > or 2-) the library uses thread specific storage which is re-used in
> >each call.
> >
> You cou
---Louis A. Mamakos said:
>> You could malloc() a struct hostent for each call to
>> gethostby*(), each time registering the hostent in some list along with the
>> thread's PID. If the same thread calls gethostby*, use the same buffer, or
>> allocate a new one if another thread calls it. Have a sta
> > ---Steve Tarkalson said:
> > > this is solved by one of two methods:
> > >1-) require the caller of gethostbyaddr() to supply a pointer to
> > >a hostent struct which will be filled.
> > > or 2-) the library uses thread specific storage which is re-used in
> > >each call.
>
---Louis A. Mamakos said:
>> ---Steve Tarkalson said:
>> > this is solved by one of two methods:
>> >1-) require the caller of gethostbyaddr() to supply a pointer to
>> >a hostent struct which will be filled.
>> > or 2-) the library uses thread specific storage which is re-used in
>> >
| Well, I guess we might as well change the API, since everyone else does.
Unless
| someone comes up with a bettter idea, of course :)
|
| -Joe
The API should not change. There is already enough descrepency between UNIXs
to warrant programs like autoconf, we should not introduce another.
We sh
---Dan Moschuk said:
>
> | Well, I guess we might as well change the API, since everyone else does.
> Unless
> | someone comes up with a bettter idea, of course :)
> |
> | -Joe
>
> The API should not change. There is already enough descrepency between UNIXs
> to warrant programs like autoconf,
Joe Groff wrote:
>
> ---Louis A. Mamakos said:
> >> You could malloc() a struct hostent for each call to
> >> gethostby*(), each time registering the hostent in some list along with the
> >> thread's PID. If the same thread calls gethostby*, use the same buffer, or
> >> allocate a new one if anoth
Joe Groff wrote:
>
> ---Dan Moschuk said:
> >
> > | Well, I guess we might as well change the API, since everyone else does.
> > Unless
> > | someone comes up with a bettter idea, of course :)
> > |
> > | -Joe
> >
> > The API should not change. There is already enough descrepency between
> > UNI
On Mon, 9 Aug 1999, Wes Peters wrote:
> Here are the prototypes. Hosts:
>
> #include
> #include
> #include
> #include
> #include
>
> struct hostent *gethostbyname_r(const char *name,
> struct hostent *result, char *buffer, int buflen,
> i
Joe Groff wrote:
>
> On Mon, 9 Aug 1999, Wes Peters wrote:
> >
> > struct rpcent *getrpcent_r(struct rpcent *result,
> > char *buffer, int buflen);
> >
> > Any questions?
>
> Looks pretty close to the POSIX/GNU way. Good luck with it.
;^) Straight from the Solaris man pages. Shou
Dan Moschuk wrote:
>
>A quicker fix would be just to enclose those global variables in
>mutexes.
God, no. The resolver is already stupidly unparallelizable -- there's
no need to make it thread-resistant too.
Tony.
--
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix
To Unsubsc
On Aug 9, 9:21pm, Dan Moschuk wrote:
} Subject: Re: gethostbyaddr() and threads.
}
} | Well, I guess we might as well change the API, since everyone else does.
Unless
} | someone comes up with a bettter idea, of course :)
} |
} | -Joe
}
} The API should not change. There is already enough
>> gethostbyaddr... actually, most of the gethostby* functions... are not
>> thread safe. They all use a static buffer in the library.
>>
>> Therefore, with threads, if you don't take precautions, I'd expect your
>> results to be odd.
>> -Brian
>>
>Couldn't this be easily fixed? I haven't loo
| > Yeah, that IS a horrible idea of mine. :) Changing the API should be a last
| > resort, though, since we don't want to introduce to many FreeBSDisms into
the
| > already-fragmented-enough Unix world.
| >
| > Just a thought, how does Linux's GNU libc handle gethostby* in threaded
apps?
|
|
| } If no one has any objections, I'd like to start on this tomorrow.
|
| You might want to grab the latest BIND release from ftp.isc.org. One
| of the comments in the CHANGES file from a while ago is:
|
| 384. [feature] there is now a nearly-thread-safe resolver API, with
|
Dan Moschuk wrote:
>
> | > Yeah, that IS a horrible idea of mine. :) Changing the API should be a
> last
> | > resort, though, since we don't want to introduce to many FreeBSDisms into
> the
> | > already-fragmented-enough Unix world.
> | >
> | > Just a thought, how does Linux's GNU libc handle
On Tue, 10 Aug 1999, Wes Peters wrote:
> Dan Moschuk wrote:
> >
> > | > Yeah, that IS a horrible idea of mine. :) Changing the API should be a
> > last
> > | > resort, though, since we don't want to introduce to many FreeBSDisms
> > into the
> > | > already-fragmented-enough Unix world.
> > |
Dan Moschuk wrote:
>
> Does anyone have any issues with merging the new bind resolver API into
> libc?
Well, Terry does, though I don't quite recall his reasoning. :-)
Notice, he objects the way FreeBSD is today, with the bind resolver
API inside libc.
Of foremost importance, though, check the l
In message <37b05320.e6722...@newsguy.com> "Daniel C. Sobral" writes:
: Well, Terry does, though I don't quite recall his reasoning. :-)
: Notice, he objects the way FreeBSD is today, with the bind resolver
: API inside libc.
The size of _res has changed. Although it starts with an _, it is
offic
"Daniel C. Sobral" writes:
> Of foremost importance, though, check the license.
Are we still talking about irs? I don't find any particular strange
licenses in src/lib/irs in recent bind distributions:
/assar
/*
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
* Permission to us
>
> Dan Moschuk wrote:
> >
> > Does anyone have any issues with merging the new bind resolver API into
> > libc?
>
> Well, Terry does, though I don't quite recall his reasoning. :-)
> Notice, he objects the way FreeBSD is today, with the bind resolver
> API inside libc.
I object because it perp
Terry Lambert wrote:
> I object because it perpetuates a situation which has made it
> take this long to get the issue addressed.
>
> I also object because BIND 9 is currently in the works, and there
> is talk of replacing the records with A6 records in the DNSEXT
> working group.
>
> The r
Dan Moschuk <[EMAIL PROTECTED]> wrote:
>
>After quite an exhausting night (of all the ways I didn't want to spend my
>Sunday...) I've managed to track down a problem that has been frustrating me
>all night. The problem exists with multiple threads calling gethostbyaddr()
>(not necessarily at the
| >After quite an exhausting night (of all the ways I didn't want to spend my
| >Sunday...) I've managed to track down a problem that has been frustrating me
| >all night. The problem exists with multiple threads calling gethostbyaddr()
| >(not necessarily at the same time).
|
| src/lib/libc/
Dan Moschuk wrote:
>
> | >After quite an exhausting night (of all the ways I didn't want to spend my
> | >Sunday...) I've managed to track down a problem that has been frustrating me
> | >all night. The problem exists with multiple threads calling gethostbyaddr()
> | >(not necessarily at the sam
[snip]
gethostbyaddr... actually, most of the gethostby* functions... are not
thread safe. They all use a static buffer in the library.
Therefore, with threads, if you don't take precautions, I'd expect your
results to be odd.
-Brian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
---Brian McGovern said:
> [snip]
>
> gethostbyaddr... actually, most of the gethostby* functions... are not
> thread safe. They all use a static buffer in the library.
>
> Therefore, with threads, if you don't take precautions, I'd expect your
> results to be odd.
> -Brian
>
Couldn't this b
y-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: Re: gethostbyaddr() and threads.
>Date: Mon, 9 Aug 1999 14:21:38 -0700 (PDT)
>MIME-Version: 1.0
>From [EMAIL PROTECTED] Mon Aug 9 14:22:43 1999
>Received: by hub.freebsd.org (Postf
---Steve Tarkalson said:
> this is solved by one of two methods:
>1-) require the caller of gethostbyaddr() to supply a pointer to
>a hostent struct which will be filled.
> or 2-) the library uses thread specific storage which is re-used in
>each call.
>
You could malloc() a s
> ---Steve Tarkalson said:
> > this is solved by one of two methods:
> >1-) require the caller of gethostbyaddr() to supply a pointer to
> >a hostent struct which will be filled.
> > or 2-) the library uses thread specific storage which is re-used in
> >each call.
> >
> You co
---Louis A. Mamakos said:
>> You could malloc() a struct hostent for each call to
>> gethostby*(), each time registering the hostent in some list along with the
>> thread's PID. If the same thread calls gethostby*, use the same buffer, or
>> allocate a new one if another thread calls it. Have a st
> > ---Steve Tarkalson said:
> > > this is solved by one of two methods:
> > >1-) require the caller of gethostbyaddr() to supply a pointer to
> > >a hostent struct which will be filled.
> > > or 2-) the library uses thread specific storage which is re-used in
> > >each call.
>
---Louis A. Mamakos said:
>> ---Steve Tarkalson said:
>> > this is solved by one of two methods:
>> >1-) require the caller of gethostbyaddr() to supply a pointer to
>> >a hostent struct which will be filled.
>> > or 2-) the library uses thread specific storage which is re-used in
>> >
| Well, I guess we might as well change the API, since everyone else does. Unless
| someone comes up with a bettter idea, of course :)
|
| -Joe
The API should not change. There is already enough descrepency between UNIXs
to warrant programs like autoconf, we should not introduce another.
We sh
---Dan Moschuk said:
>
> | Well, I guess we might as well change the API, since everyone else does.
> Unless
> | someone comes up with a bettter idea, of course :)
> |
> | -Joe
>
> The API should not change. There is already enough descrepency between UNIXs
> to warrant programs like autoconf,
Joe Groff wrote:
>
> ---Louis A. Mamakos said:
> >> You could malloc() a struct hostent for each call to
> >> gethostby*(), each time registering the hostent in some list along with the
> >> thread's PID. If the same thread calls gethostby*, use the same buffer, or
> >> allocate a new one if anot
Joe Groff wrote:
>
> ---Dan Moschuk said:
> >
> > | Well, I guess we might as well change the API, since everyone else does.
> > Unless
> > | someone comes up with a bettter idea, of course :)
> > |
> > | -Joe
> >
> > The API should not change. There is already enough descrepency between UNIXs
>
On Mon, 9 Aug 1999, Wes Peters wrote:
> Here are the prototypes. Hosts:
>
> #include
> #include
> #include
> #include
> #include
>
> struct hostent *gethostbyname_r(const char *name,
> struct hostent *result, char *buffer, int buflen,
>
Joe Groff wrote:
>
> On Mon, 9 Aug 1999, Wes Peters wrote:
> >
> > struct rpcent *getrpcent_r(struct rpcent *result,
> > char *buffer, int buflen);
> >
> > Any questions?
>
> Looks pretty close to the POSIX/GNU way. Good luck with it.
;^) Straight from the Solaris man pages. Sho
Dan Moschuk <[EMAIL PROTECTED]> wrote:
>
>A quicker fix would be just to enclose those global variables in
>mutexes.
God, no. The resolver is already stupidly unparallelizable -- there's
no need to make it thread-resistant too.
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e
On Aug 9, 9:21pm, Dan Moschuk wrote:
} Subject: Re: gethostbyaddr() and threads.
}
} | Well, I guess we might as well change the API, since everyone else does. Unless
} | someone comes up with a bettter idea, of course :)
} |
} | -Joe
}
} The API should not change. There is already enough
>> gethostbyaddr... actually, most of the gethostby* functions... are not
>> thread safe. They all use a static buffer in the library.
>>
>> Therefore, with threads, if you don't take precautions, I'd expect your
>> results to be odd.
>> -Brian
>>
>Couldn't this be easily fixed? I haven't lo
| > Yeah, that IS a horrible idea of mine. :) Changing the API should be a last
| > resort, though, since we don't want to introduce to many FreeBSDisms into the
| > already-fragmented-enough Unix world.
| >
| > Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps?
|
| P
| } If no one has any objections, I'd like to start on this tomorrow.
|
| You might want to grab the latest BIND release from ftp.isc.org. One
| of the comments in the CHANGES file from a while ago is:
|
| 384. [feature] there is now a nearly-thread-safe resolver API, with
|
Dan Moschuk wrote:
>
> | > Yeah, that IS a horrible idea of mine. :) Changing the API should be a last
> | > resort, though, since we don't want to introduce to many FreeBSDisms into the
> | > already-fragmented-enough Unix world.
> | >
> | > Just a thought, how does Linux's GNU libc handle getho
On Tue, 10 Aug 1999, Wes Peters wrote:
> Dan Moschuk wrote:
> >
> > | > Yeah, that IS a horrible idea of mine. :) Changing the API should be a last
> > | > resort, though, since we don't want to introduce to many FreeBSDisms into the
> > | > already-fragmented-enough Unix world.
> > | >
> > |
Dan Moschuk wrote:
>
> Does anyone have any issues with merging the new bind resolver API into
> libc?
Well, Terry does, though I don't quite recall his reasoning. :-)
Notice, he objects the way FreeBSD is today, with the bind resolver
API inside libc.
Of foremost importance, though, check the
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
: Well, Terry does, though I don't quite recall his reasoning. :-)
: Notice, he objects the way FreeBSD is today, with the bind resolver
: API inside libc.
The size of _res has changed. Although it starts with an _, it is
officially part
"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> Of foremost importance, though, check the license.
Are we still talking about irs? I don't find any particular strange
licenses in src/lib/irs in recent bind distributions:
/assar
/*
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
>
> Dan Moschuk wrote:
> >
> > Does anyone have any issues with merging the new bind resolver API into
> > libc?
>
> Well, Terry does, though I don't quite recall his reasoning. :-)
> Notice, he objects the way FreeBSD is today, with the bind resolver
> API inside libc.
I object because it per
Terry Lambert wrote:
> I object because it perpetuates a situation which has made it
> take this long to get the issue addressed.
>
> I also object because BIND 9 is currently in the works, and there
> is talk of replacing the records with A6 records in the DNSEXT
> working group.
>
> The
60 matches
Mail list logo
