Date: Mon, 15 Sep 1997 05:37:15 +0200 (CEST) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: tlambert@primenet.com (Terry Lambert) Cc: hackers@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? Message-ID: <199709150337.FAA01640@ocean.campus.luth.se> In-Reply-To: <199709150222.TAA11074@usr09.primenet.com> from Terry Lambert at "Sep 15, 97 02:22:55 am"
next in thread | previous in thread | raw e-mail | index | archive | help
[... CC trimmed ...] According to Terry Lambert: > > That seems... DUMB! Returning something that the user must free instead of > > static buffers, when that's the normal behaviour is just very very bad. > > Say I have one of these little jewels of a function: [Example showing that you should not use "static" in MT programs. Obvious.] Terry... I often get annoyed with people tending to discard you just because you are you. But sometimes you really seem to put effort into missing the point, or straying away from the main discussion. And I'm not talking just this message... > > Three words: Thread local storage. > > One function name: > > CreateFreeeThreadedMarshallerSoICanGetAtMyOwnDamnAddressSpace() > > for instanced classes and objects. > > The *really* correct way to fix this is: > > somefunction( arguments, user_buffer_for_result); > > This ensures the data is thread local, without totally screwing up > the ability to pass data by pointer among threads. [...] Yes, this is one obvious solution. *_r calls. It's gives a "clean" implementation. Which _is_ nice. But it also kills the interface. > > Let each tread have its OWN static buffer. This is actually nicer in some > > ways then having the programmer pass buffers to pointers, etc, in *_r > > versions of calls. It's nicer because it's less work for the user of the > > library. And returning something the user must free is just out of the > > question. That's ugly beyond belief. Everyone deals with their own memory. > > Libraries too. > > Static buffers in library functions are what is ugly beyond belief. Not freeing the memory you allocate is really Bad. Exceptions ofcourse, where malloc() is a given. Static buffers in libraries are ugly, true. But it gives a very nice (simple) interface. And most of all, that's how the standard looks. And there's not a whole lot we can do about it. In C++ you can get the same nice interface, but without static buffers. You simply return string-class objects, etc, instead of a char * to a static buffer. But we're not talking C++ interface here. We're talking libc. And making it threadsafe in the nicest way possible is, IMO, to do it in an invisible and yet threadsafe way. That's what I suggested. They do it that way in Solaris, which I've been using at work, and I think it's a terriffic solution. You just add "-mt" to CC and it will pick up threadsafe versions of functions, with no interface change. TADA! Excellent solution. And I don't care HOW they did it. It's nice. I'd really like to see the same thing in FreeBSD. If they have a sucky implementation, or my quickly thought up implementation- suggestion was bad is irrellevant. Implement it better in FreeBSD, then. Just keep the interface, because that is a Good Thing(tm). > > All that is needed is [ ... ] > > Congradulations; you've reinvented intra-process inter-thread data > marshalling... welcome to the Microsoft "Viper" framework and the > ActiveX Template Library version 1.2. Cool. They should pay me rolayties for stealing my idea before I even thought of it! ;-) See below and above. > > Then just allocate that struct with malloc, and make a pointer > > in TLS point to it. [ ... ] > > But why stop at Microsoft's Common Object Model (the UNIX version is > called CORBA, by the way, and is generally preferred by UNIX people, > as it's an open standard -- ie: documented somewhere), when you can > go full steam ahead and invent Macintosh memory handles as well? > > AUGH! I don't know too much about CORBA, I'm affraid, but again: I really don't care if microsoft thought of it first, or if it's a lib in X11, or if the source can be found in the moon. The idea is fine, IMO, and my little code example should work just fine, and shouldn't be too slow, with some more then my five minutes of thought put into it. Something like 2-3 extra pointer dereferences per call to a function which now uses static buffers should REALLY not matter much. In short: Tell me something new, Terry. I know not to use static in MT progs. I also see the possiblity of user supplied buffer, but that changes the interface. Bad. /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709150337.FAA01640>