Re: gethostbyaddr() and threads.
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 resolver should be in a seperate library to facilitate speedy > integration of future releases, and because its designers put it > in a seperate library. > > The correct way to get historical BSD behaviour, i.e. linking libc > gives you the resolver, is to take advantage of ELF, and link the > libc against the libresolver, and thus incorporate it by reference > (if this doesn't work in FreeBSD, it should; I haven't checked). > > Of course, my ideal world would update all of the Makefiles for > all of the network utilities (including the ports) to know about > libresolver explicitly, but that's unlikely to come to pass. Here here. Think of this as a "me too," or a vote in favor of each of the points above. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 resolver should be in a seperate library to facilitate speedy > integration of future releases, and because its designers put it > in a seperate library. > > The correct way to get historical BSD behaviour, i.e. linking libc > gives you the resolver, is to take advantage of ELF, and link the > libc against the libresolver, and thus incorporate it by reference > (if this doesn't work in FreeBSD, it should; I haven't checked). > > Of course, my ideal world would update all of the Makefiles for > all of the network utilities (including the ports) to know about > libresolver explicitly, but that's unlikely to come to pass. Here here. Think of this as a "me too," or a vote in favor of each of the points above. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> > 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 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 resolver should be in a seperate library to facilitate speedy integration of future releases, and because its designers put it in a seperate library. The correct way to get historical BSD behaviour, i.e. linking libc gives you the resolver, is to take advantage of ELF, and link the libc against the libresolver, and thus incorporate it by reference (if this doesn't work in FreeBSD, it should; I haven't checked). Of course, my ideal world would update all of the Makefiles for all of the network utilities (including the ports) to know about libresolver explicitly, but that's unlikely to come to pass. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> > 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 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 resolver should be in a seperate library to facilitate speedy integration of future releases, and because its designers put it in a seperate library. The correct way to get historical BSD behaviour, i.e. linking libc gives you the resolver, is to take advantage of ELF, and link the libc against the libresolver, and thus incorporate it by reference (if this doesn't work in FreeBSD, it should; I haven't checked). Of course, my ideal world would update all of the Makefiles for all of the network utilities (including the ports) to know about libresolver explicitly, but that's unlikely to come to pass. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
"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 use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. */ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
"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. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 officially part of the API. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 of the API. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 license. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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. > > | > > > | > Just a thought, how does Linux's GNU libc handle gethostby* in threaded > > apps? > > | > > | Probably the way POSIX specifies, which would certainly be *our* target. > > > > And does POSIX specify it? > > You didn't get the message with the function prototypes? I can send it again. > This would be the *correct* way to implement thread-safe get*by* calls, since > any existing threaded code (Solaris, Linux, etc.) will use these interfaces. Small detail, but having ported a multi-threaded library to Linux either Linux is not posix-compliant or everyone else (solaris and others) is not. It's _r API is quite different. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr > LLC > http://softweyr.com/ > w...@softweyr.com > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 gethostby* in threaded > apps? > | > | Probably the way POSIX specifies, which would certainly be *our* target. > > And does POSIX specify it? You didn't get the message with the function prototypes? I can send it again. This would be the *correct* way to implement thread-safe get*by* calls, since any existing threaded code (Solaris, Linux, etc.) will use these interfaces. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 license. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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. > > | > > > | > Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? > > | > > | Probably the way POSIX specifies, which would certainly be *our* target. > > > > And does POSIX specify it? > > You didn't get the message with the function prototypes? I can send it again. > This would be the *correct* way to implement thread-safe get*by* calls, since > any existing threaded code (Solaris, Linux, etc.) will use these interfaces. Small detail, but having ported a multi-threaded library to Linux either Linux is not posix-compliant or everyone else (solaris and others) is not. It's _r API is quite different. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > http://softweyr.com/ [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| } 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 | the old non-thread-safe API being a set of stubs on | top of this. it is possible to program without _res. | note: the documentation has not been updated. also | note: IRS is a thread-ready API, get*by*() is not. | (see ../contrib/manyhosts for an example application.) | | There's no sense re-inventing any more wheels than necessary. Great! This makes my job even easier! Does anyone have any issues with merging the new bind resolver API into libc? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| > 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? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 gethostby* in threaded apps? > | > | Probably the way POSIX specifies, which would certainly be *our* target. > > And does POSIX specify it? You didn't get the message with the function prototypes? I can send it again. This would be the *correct* way to implement thread-safe get*by* calls, since any existing threaded code (Solaris, Linux, etc.) will use these interfaces. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| } 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 | the old non-thread-safe API being a set of stubs on | top of this. it is possible to program without _res. | note: the documentation has not been updated. also | note: IRS is a thread-ready API, get*by*() is not. | (see ../contrib/manyhosts for an example application.) | | There's no sense re-inventing any more wheels than necessary. Great! This makes my job even easier! Does anyone have any issues with merging the new bind resolver API into libc? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| > 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? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
>> 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 looked at the source yet, but I >believe you could replaced the static buffers with a dynamically-allocated list >of buffers, with one for each thread using the gethost functions. Or perhaps >you could just eliminate all the static stuff altogether? -Joe You could, but thats not what was asked. Nor is the solution portable. Posix warns that these functions are not thread safe. Realistically, the portable solution would be to mutex lock (or equiv.) around the calls, so that only one thread can call the function(s) at a time, and be sure to copy the results out of the temporary buffers before releasing the locks. (see note on "if you don't take precautions") An even more interesting solution may be to write some wrappers that do the lock, call the function, and store the result in a thread-specific area, then unlock again. -Brian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 descrepency between UNIXs } to warrant programs like autoconf, we should not introduce another. } We should introduce a gethostbyaddr_r function, which shouldn't be all that } though to implement. } } >From the code that I looked at today, the problems lie inside of glibc. It } declares globally a few static variables that are used by the gethost* } functions. Obviously in a threaded environment, this is bad. } } A nice fix would be to get rid of those variables entirely. A quicker fix } would be just to enclose those global variables in mutexes. Personally, I } like the nicer fix better, which will (unfortunately) involve rewriting most } of the frontends to the res_* functions. } } 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 the old non-thread-safe API being a set of stubs on top of this. it is possible to program without _res. note: the documentation has not been updated. also note: IRS is a thread-ready API, get*by*() is not. (see ../contrib/manyhosts for an example application.) There's no sense re-inventing any more wheels than necessary. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
>> 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 looked at the source yet, but I >believe you could replaced the static buffers with a dynamically-allocated list >of buffers, with one for each thread using the gethost functions. Or perhaps >you could just eliminate all the static stuff altogether? -Joe You could, but thats not what was asked. Nor is the solution portable. Posix warns that these functions are not thread safe. Realistically, the portable solution would be to mutex lock (or equiv.) around the calls, so that only one thread can call the function(s) at a time, and be sure to copy the results out of the temporary buffers before releasing the locks. (see note on "if you don't take precautions") An even more interesting solution may be to write some wrappers that do the lock, call the function, and store the result in a thread-specific area, then unlock again. -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 descrepency between UNIXs } to warrant programs like autoconf, we should not introduce another. } We should introduce a gethostbyaddr_r function, which shouldn't be all that } though to implement. } } >From the code that I looked at today, the problems lie inside of glibc. It } declares globally a few static variables that are used by the gethost* } functions. Obviously in a threaded environment, this is bad. } } A nice fix would be to get rid of those variables entirely. A quicker fix } would be just to enclose those global variables in mutexes. Personally, I } like the nicer fix better, which will (unfortunately) involve rewriting most } of the frontends to the res_* functions. } } 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 the old non-thread-safe API being a set of stubs on top of this. it is possible to program without _res. note: the documentation has not been updated. also note: IRS is a thread-ready API, get*by*() is not. (see ../contrib/manyhosts for an example application.) There's no sense re-inventing any more wheels than necessary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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. Should be as POSIX as working code can be. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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, > int *h_errnop); > > struct hostent *gethostbyaddr_r(const char *addr, > int length, int type, struct hostent *result, > char *buffer, int buflen, int *h_errnop); > > struct hostent *gethostent_r(struct hostent *result, > char *buffer, int buflen, int *h_errnop); > > Nets: > > #include > > struct netent *getnetbyname_r(const char *name, > struct netent *result, char *buffer, int buflen); > > struct netent *getnetbyaddr_r(long net, int type, > struct netent *result, char *buffer, int buflen); > > struct netent *getnetent_r(struct netent *result, > char *buffer, int buflen); > > Protocols: > > #include > > struct protoent *getprotobyname_r(const char *name, > struct protoent *result, char *buffer, int buflen); > > struct protoent *getprotobynumber_r(int proto, > struct protoent *result, char *buffer, int buflen); > > struct protoent *getprotoent_r(struct protoent *result, > char *buffer, int buflen); > > Services: > > #include > > struct servent *getservbyname_r(const char *name, > const char *proto, struct servent *result, > char *buffer, int buflen); > > struct servent *getservbyport_r(int port, const char *proto, > struct servent *result, char *buffer, int buflen); > > struct servent *getservent_r(struct servent *result, > char *buffer, int buflen); > > RPC services: > > #include > > struct rpcent *getrpcbyname_r(const char * name, > struct rpcent *result, char *buffer, int buflen); > > struct rpcent *getrpcbynumber_r(const int number, > struct rpcent *result, char *buffer, int buflen); > > 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. -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 > > to warrant programs like autoconf, we should not introduce another. > > We should introduce a gethostbyaddr_r function, which shouldn't be all that > > though to implement. > That's what I meant by an API change. Sorry for not being clearer. > However, if you can roll in reentrancy without having to add the _r > functions, that would save some sweat on the programmers' side. No, it wouldn't, because any existing programs that already handle name server queries within threads will already use the gethostby*_r APIs. > >>From the code that I looked at today, the problems lie inside of glibc. It > > declares globally a few static variables that are used by the gethost* > > functions. Obviously in a threaded environment, this is bad. > > > > A nice fix would be to get rid of those variables entirely. A quicker fix > > would be just to enclose those global variables in mutexes. Personally, I > > like the nicer fix better, which will (unfortunately) involve rewriting most > > of the frontends to the res_* functions. > > > > If no one has any objections, I'd like to start on this tomorrow. > > > Go for it! Someone needs to. :) Here are the prototypes. Hosts: #include #include #include #include #include struct hostent *gethostbyname_r(const char *name, struct hostent *result, char *buffer, int buflen, int *h_errnop); struct hostent *gethostbyaddr_r(const char *addr, int length, int type, struct hostent *result, char *buffer, int buflen, int *h_errnop); struct hostent *gethostent_r(struct hostent *result, char *buffer, int buflen, int *h_errnop); Nets: #include struct netent *getnetbyname_r(const char *name, struct netent *result, char *buffer, int buflen); struct netent *getnetbyaddr_r(long net, int type, struct netent *result, char *buffer, int buflen); struct netent *getnetent_r(struct netent *result, char *buffer, int buflen); Protocols: #include struct protoent *getprotobyname_r(const char *name, struct protoent *result, char *buffer, int buflen); struct protoent *getprotobynumber_r(int proto, struct protoent *result, char *buffer, int buflen); struct protoent *getprotoent_r(struct protoent *result, char *buffer, int buflen); Services: #include struct servent *getservbyname_r(const char *name, const char *proto, struct servent *result, char *buffer, int buflen); struct servent *getservbyport_r(int port, const char *proto, struct servent *result, char *buffer, int buflen); struct servent *getservent_r(struct servent *result, char *buffer, int buflen); RPC services: #include struct rpcent *getrpcbyname_r(const char * name, struct rpcent *result, char *buffer, int buflen); struct rpcent *getrpcbynumber_r(const int number, struct rpcent *result, char *buffer, int buflen); struct rpcent *getrpcent_r(struct rpcent *result, char *buffer, int buflen); Any questions? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 another thread calls it. Have a static function be > > called > >> atexit to free all the mallocs. > > > > Yuk! > > > > If you're writing a multithreaded program, a slightly different API for > > gethostbyname() is likely to be the least of your worries. > > > 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? Probably the way POSIX specifies, which would certainly be *our* target. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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. Should be as POSIX as working code can be. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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, > int *h_errnop); > > struct hostent *gethostbyaddr_r(const char *addr, > int length, int type, struct hostent *result, > char *buffer, int buflen, int *h_errnop); > > struct hostent *gethostent_r(struct hostent *result, > char *buffer, int buflen, int *h_errnop); > > Nets: > > #include > > struct netent *getnetbyname_r(const char *name, > struct netent *result, char *buffer, int buflen); > > struct netent *getnetbyaddr_r(long net, int type, > struct netent *result, char *buffer, int buflen); > > struct netent *getnetent_r(struct netent *result, > char *buffer, int buflen); > > Protocols: > > #include > > struct protoent *getprotobyname_r(const char *name, > struct protoent *result, char *buffer, int buflen); > > struct protoent *getprotobynumber_r(int proto, > struct protoent *result, char *buffer, int buflen); > > struct protoent *getprotoent_r(struct protoent *result, > char *buffer, int buflen); > > Services: > > #include > > struct servent *getservbyname_r(const char *name, > const char *proto, struct servent *result, > char *buffer, int buflen); > > struct servent *getservbyport_r(int port, const char *proto, > struct servent *result, char *buffer, int buflen); > > struct servent *getservent_r(struct servent *result, > char *buffer, int buflen); > > RPC services: > > #include > > struct rpcent *getrpcbyname_r(const char * name, > struct rpcent *result, char *buffer, int buflen); > > struct rpcent *getrpcbynumber_r(const int number, > struct rpcent *result, char *buffer, int buflen); > > 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. -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 > > to warrant programs like autoconf, we should not introduce another. > > We should introduce a gethostbyaddr_r function, which shouldn't be all that > > though to implement. > That's what I meant by an API change. Sorry for not being clearer. > However, if you can roll in reentrancy without having to add the _r > functions, that would save some sweat on the programmers' side. No, it wouldn't, because any existing programs that already handle name server queries within threads will already use the gethostby*_r APIs. > >>From the code that I looked at today, the problems lie inside of glibc. It > > declares globally a few static variables that are used by the gethost* > > functions. Obviously in a threaded environment, this is bad. > > > > A nice fix would be to get rid of those variables entirely. A quicker fix > > would be just to enclose those global variables in mutexes. Personally, I > > like the nicer fix better, which will (unfortunately) involve rewriting most > > of the frontends to the res_* functions. > > > > If no one has any objections, I'd like to start on this tomorrow. > > > Go for it! Someone needs to. :) Here are the prototypes. Hosts: #include #include #include #include #include struct hostent *gethostbyname_r(const char *name, struct hostent *result, char *buffer, int buflen, int *h_errnop); struct hostent *gethostbyaddr_r(const char *addr, int length, int type, struct hostent *result, char *buffer, int buflen, int *h_errnop); struct hostent *gethostent_r(struct hostent *result, char *buffer, int buflen, int *h_errnop); Nets: #include struct netent *getnetbyname_r(const char *name, struct netent *result, char *buffer, int buflen); struct netent *getnetbyaddr_r(long net, int type, struct netent *result, char *buffer, int buflen); struct netent *getnetent_r(struct netent *result, char *buffer, int buflen); Protocols: #include struct protoent *getprotobyname_r(const char *name, struct protoent *result, char *buffer, int buflen); struct protoent *getprotobynumber_r(int proto, struct protoent *result, char *buffer, int buflen); struct protoent *getprotoent_r(struct protoent *result, char *buffer, int buflen); Services: #include struct servent *getservbyname_r(const char *name, const char *proto, struct servent *result, char *buffer, int buflen); struct servent *getservbyport_r(int port, const char *proto, struct servent *result, char *buffer, int buflen); struct servent *getservent_r(struct servent *result, char *buffer, int buflen); RPC services: #include struct rpcent *getrpcbyname_r(const char * name, struct rpcent *result, char *buffer, int buflen); struct rpcent *getrpcbynumber_r(const int number, struct rpcent *result, char *buffer, int buflen); struct rpcent *getrpcent_r(struct rpcent *result, char *buffer, int buflen); Any questions? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 another thread calls it. Have a static function be > > called > >> atexit to free all the mallocs. > > > > Yuk! > > > > If you're writing a multithreaded program, a slightly different API for > > gethostbyname() is likely to be the least of your worries. > > > 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? Probably the way POSIX specifies, which would certainly be *our* target. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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, we should not introduce another. > We should introduce a gethostbyaddr_r function, which shouldn't be all that > though to implement. That's what I meant by an API change. Sorry for not being clearer. However, if you can roll in reentrancy without having to add the _r functions, that would save some sweat on the programmers' side. >>From the code that I looked at today, the problems lie inside of glibc. It > declares globally a few static variables that are used by the gethost* > functions. Obviously in a threaded environment, this is bad. > > A nice fix would be to get rid of those variables entirely. A quicker fix > would be just to enclose those global variables in mutexes. Personally, I > like the nicer fix better, which will (unfortunately) involve rewriting most > of the frontends to the res_* functions. > > If no one has any objections, I'd like to start on this tomorrow. > Go for it! Someone needs to. :) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
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 descrepency between UNIXs to warrant programs like autoconf, we should not introduce another. We should introduce a gethostbyaddr_r function, which shouldn't be all that though to implement.
Re: gethostbyaddr() and threads.
---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 >> >each call. >> > >> 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 static function be > called >> atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. > 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 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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, we should not introduce another. > We should introduce a gethostbyaddr_r function, which shouldn't be all that > though to implement. That's what I meant by an API change. Sorry for not being clearer. However, if you can roll in reentrancy without having to add the _r functions, that would save some sweat on the programmers' side. >>From the code that I looked at today, the problems lie inside of glibc. It > declares globally a few static variables that are used by the gethost* > functions. Obviously in a threaded environment, this is bad. > > A nice fix would be to get rid of those variables entirely. A quicker fix > would be just to enclose those global variables in mutexes. Personally, I > like the nicer fix better, which will (unfortunately) involve rewriting most > of the frontends to the res_* functions. > > If no one has any objections, I'd like to start on this tomorrow. > Go for it! Someone needs to. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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 descrepency between UNIXs to warrant programs like autoconf, we should not introduce another. We should introduce a gethostbyaddr_r function, which shouldn't be all that though to implement. >From the code that I looked at today, the problems lie inside of glibc. It declares globally a few static variables that are used by the gethost* functions. Obviously in a threaded environment, this is bad. A nice fix would be to get rid of those variables entirely. A quicker fix would be just to enclose those global variables in mutexes. Personally, I like the nicer fix better, which will (unfortunately) involve rewriting most of the frontends to the res_* functions. If no one has any objections, I'd like to start on this tomorrow. Thanks, Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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 >> >each call. >> > >> 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 static function be > called >> atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> > ---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 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 static function be > > called > > atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. Agreed. gethostbyname_r() on solaris requires the caller to provide the address to write into, which is IMO the correct solution. Yes, it's a different API. But, the other alternatives are worse. The user must be able to control his memory allocation. For example, in a typical networking application, gethostbyname() could be called thousands or millions of times, and allocating memory everytime that can't be cleaned up until the program exits is completely unacceptable. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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 static function be > called >> atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. > 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? -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> ---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 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 static function be > called > atexit to free all the mallocs. Yuk! If you're writing a multithreaded program, a slightly different API for gethostbyname() is likely to be the least of your worries. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> > ---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 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 static function be called > > atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. Agreed. gethostbyname_r() on solaris requires the caller to provide the address to write into, which is IMO the correct solution. Yes, it's a different API. But, the other alternatives are worse. The user must be able to control his memory allocation. For example, in a typical networking application, gethostbyname() could be called thousands or millions of times, and allocating memory everytime that can't be cleaned up until the program exits is completely unacceptable. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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 static function be > called >> atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. > 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? -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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 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 static function be called atexit to free all the mallocs. -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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. From: Joe Groff Reply-To: og...@humboldt1.com To: bmcgo...@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 Aug 1999 14:24:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org (Postfix) with SMTPid F31551CD65D; Mon, 9 Aug 1999 14:24:35 -0700 (PDT)(envelope-from owner-freebsd-hackers) Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 9 Aug 1999 14:24:35 -0700 Delivered-To: freebsd-hackers@freebsd.org Received: from home.humboldt1.com (home.humboldt1.com [206.13.45.1])by hub.freebsd.org (Postfix) with ESMTP id 9598214D75for ; Mon, 9 Aug 1999 14:24:29 -0700 (PDT)(envelope-from og...@humboldt1.com) Received: from shovel.groff (ppp176-pm5.humboldt1.com [207.104.21.169])by home.humboldt1.com (Pro-8.9.2/Pro-8.9.2) with SMTP id OAA21266;Mon, 9 Aug 1999 14:21:38 -0700 (PDT) Message-Id: <199908092121.oaa21...@home.humboldt1.com> In-Reply-To: <199908092104.raa06...@bmcgover-pc.cisco.com> X-Mailer: XCmail 1.0.0 - with PGP support, PGP engine version 0.5 (FreeBSD) X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ Sender: owner-freebsd-hack...@freebsd.org X-Loop: FreeBSD.ORG Precedence: bulk ---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 easily fixed? I haven't looked at the source yet, but I believe you could replaced the static buffers with a dynamically-allocated list of buffers, with one for each thread using the gethost functions. Or perhaps you could just eliminate all the static stuff altogether? -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message ___ Get Free Email and Do More On The Web. Visit http://www.msn.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> ---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 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 static function be called > atexit to free all the mallocs. Yuk! If you're writing a multithreaded program, a slightly different API for gethostbyname() is likely to be the least of your worries. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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 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 static function be called atexit to free all the mallocs. -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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. >From: Joe Groff <[EMAIL PROTECTED]> >Reply-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 (Postfix, from userid 538)id 13F1E152DC; Mon, >9 Aug 1999 14:24:36 -0700 (PDT) >Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org >(Postfix) with SMTPid F31551CD65D; Mon, 9 Aug 1999 14:24:35 -0700 >(PDT)(envelope-from owner-freebsd-hackers) >Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 9 Aug 1999 14:24:35 >-0700 >Delivered-To: [EMAIL PROTECTED] >Received: from home.humboldt1.com (home.humboldt1.com [206.13.45.1])by >hub.freebsd.org (Postfix) with ESMTP id 9598214D75for ><[EMAIL PROTECTED]>; Mon, 9 Aug 1999 14:24:29 -0700 (PDT)(envelope-from >[EMAIL PROTECTED]) >Received: from shovel.groff (ppp176-pm5.humboldt1.com [207.104.21.169])by >home.humboldt1.com (Pro-8.9.2/Pro-8.9.2) with SMTP id OAA21266;Mon, 9 Aug >1999 14:21:38 -0700 (PDT) >Message-Id: <[EMAIL PROTECTED]> >In-Reply-To: <[EMAIL PROTECTED]> >X-Mailer: XCmail 1.0.0 - with PGP support, PGP engine version 0.5 (FreeBSD) >X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ >Sender: [EMAIL PROTECTED] >X-Loop: FreeBSD.ORG >Precedence: bulk > >---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 easily fixed? I haven't looked at the source yet, but I >believe you could replaced the static buffers with a dynamically-allocated >list >of buffers, with one for each thread using the gethost functions. Or >perhaps >you could just eliminate all the static stuff altogether? > >-Joe > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-hackers" in the body of the message > ___ Get Free Email and Do More On The Web. Visit http://www.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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 easily fixed? I haven't looked at the source yet, but I believe you could replaced the static buffers with a dynamically-allocated list of buffers, with one for each thread using the gethost functions. Or perhaps you could just eliminate all the static stuff altogether? -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
[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 with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---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 easily fixed? I haven't looked at the source yet, but I believe you could replaced the static buffers with a dynamically-allocated list of buffers, with one for each thread using the gethost functions. Or perhaps you could just eliminate all the static stuff altogether? -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
[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 "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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/lib/libc/net/gethostbydns.c seems to use a load of static > | variables in a non-thread-safe fashion. > > Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked > "less" than gethostbyaddr did (the result was that all threads ended up > thrashing each other, and not of them continued on). I was going to use > res_query, but noticed that it too used static buffers (although it looks > pretty easy to fix). > > Would anyone be offended if I were to produce a few patches to fix up these > routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs > or try full blown routines (gethostbyaddr_r, res_query_r)? This is the second request for gethostbyaddr_r I've seen this week. I've been (oh so slowly) implementing the missing _r routines in our library and documenting the hidden ones I've already found. This is one of the uglier ones. Hacking up the mess we've got would be a waste of time, IMHO. If you're going to do it, go all the way and make a CLEAN implementation of the _r routines and then implement the non _r routines on top of them. If you need prototypes, email back and I'll find the ones you want to work on first. When you're done, send me files or diffs and I'll be very happy to test them for you. I'll even help with the man pages. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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/lib/libc/net/gethostbydns.c seems to use a load of static > | variables in a non-thread-safe fashion. > > Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked > "less" than gethostbyaddr did (the result was that all threads ended up > thrashing each other, and not of them continued on). I was going to use > res_query, but noticed that it too used static buffers (although it looks > pretty easy to fix). > > Would anyone be offended if I were to produce a few patches to fix up these > routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs > or try full blown routines (gethostbyaddr_r, res_query_r)? This is the second request for gethostbyaddr_r I've seen this week. I've been (oh so slowly) implementing the missing _r routines in our library and documenting the hidden ones I've already found. This is one of the uglier ones. Hacking up the mess we've got would be a waste of time, IMHO. If you're going to do it, go all the way and make a CLEAN implementation of the _r routines and then implement the non _r routines on top of them. If you need prototypes, email back and I'll find the ones you want to work on first. When you're done, send me files or diffs and I'll be very happy to test them for you. I'll even help with the man pages. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| >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/net/gethostbydns.c seems to use a load of static | variables in a non-thread-safe fashion. Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked "less" than gethostbyaddr did (the result was that all threads ended up thrashing each other, and not of them continued on). I was going to use res_query, but noticed that it too used static buffers (although it looks pretty easy to fix). Would anyone be offended if I were to produce a few patches to fix up these routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs or try full blown routines (gethostbyaddr_r, res_query_r)? Thanks, Dan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| >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/net/gethostbydns.c seems to use a load of static | variables in a non-thread-safe fashion. Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked "less" than gethostbyaddr did (the result was that all threads ended up thrashing each other, and not of them continued on). I was going to use res_query, but noticed that it too used static buffers (although it looks pretty easy to fix). Would anyone be offended if I were to produce a few patches to fix up these routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs or try full blown routines (gethostbyaddr_r, res_query_r)? Thanks, Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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/lib/libc/net/gethostbydns.c seems to use a load of static variables in a non-thread-safe fashion. Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
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 same time). src/lib/libc/net/gethostbydns.c seems to use a load of static variables in a non-thread-safe fashion. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
