Date: Mon, 15 Sep 1997 07:07:28 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: karpen@ocean.campus.luth.se (Mikael Karpberg) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? Message-ID: <199709150707.AAA16919@usr04.primenet.com> In-Reply-To: <199709150337.FAA01640@ocean.campus.luth.se> from "Mikael Karpberg" at Sep 15, 97 05:37:15 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. The threading interface and the non-threading interface should be the same. On that, I think we agree. But we are now at odds with the standard because of this, since POSIX threading specified the _r functions behavioral differences in like of threading. One possibility is to provide a set of library routines that take a user buffer and fill it in. Provide legacy compatability with inline functions that use static buffers as the argument to the real functions. This immediately buys the functions into being threadsafe as well, since each reference instance will have its own buffer. Alternately, provide a posix.o in the libc.a archive that contains unsafe stub functions. The threading can be done the POSIX way, where space is allocated, used as an argument to the refexive functions, and returned, or it can be done your way, where stub functions allocate thread local storage onces there's such a thing as thread local storage that can be mapped into the same location regardless of address space. In general, except for compatability stub functions, externally exported static or global data does not belong in libraries. > 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. It's possible to provide dynmaic scoping in C as well. It's just high overhead. Just as it is in C++. Which is one of the reasons the kernel isn't written in C++. But it *is* possible. > 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. They use thread attach and detach mechanisms to instance the static data areas, just as uninitialized static and global data is not linked into a program image, it is instanced when the process attaches the library. If you were to provide thread_attach() and thread_detach() methods for each library, and teach dlopen() and dlclose() about them, and then add this code to each library, and then teach crt0 to do a process_attach() and process_detach() (thread0, actually), then maybe you could implement this without splitting the heap along the lines of "thread local storage" and splitting the process memeory map so that thread context switches were as high overhead as Windows 95, NT, or Solaris, all of which do this type of thing instead of keeping a single heap. It'd be a lot of work, and it would tend to make FreeBSD libraries (and dlopen'able shared objects, which must also have them) look a lot like Windows DLL's, but it could be done. And all to: > Just keep the interface, because that is a Good Thing(tm). With respect, ANSI C changed C, and other than me, and a few others (and maybe Dennis Ritchie, until Prentice hall bought him for "The C Programming Language, Second Edition"), no one cared. ANSI had the best of intentions: they changed the language to accommodate considerations that hadn't been there when it was designed... and for better or worse, they added things like ambitious optimizations that caused it so that syntax changes like volatile Could Not Be Ignored, and they added prototypes so that Microsoft Windows programmers didn't have to worry about "near" or "far" when prototypes were in scope for the functions that needed them. Well, friends, POSIX and ANSI didn't consider threading, either, and it's time for another sea-change to occur. This time, it's the standard libraries. And while we're in there, we need to git rid of namespace degradations used to dummy up in-band return values, and all of the other stuff which we now know is nothing but BS, but which has been codified by a standard that controls 8% of the computer market, and in so doing is somehow ennobled, and none dare criticize it. You want crappy compatability functions? Fine. Put them in a compatability module and in header files as inlines. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709150707.AAA16919>