Date: Thu, 18 Sep 1997 17:02:57 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jb@cimlogic.com.au (John Birrell) Cc: ianh@saturn-tech.com, jb@cimlogic.com.au, freebsd-current@FreeBSD.ORG Subject: Re: Thread safe libc Message-ID: <199709181702.KAA20721@usr03.primenet.com> In-Reply-To: <199709182309.XAA08877@freebsd1.cimlogic.com.au> from "John Birrell" at Sep 18, 97 11:09:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Like you, I prefer that the replacements for the statics be allocated > with thread specific data, then they call the appropriate _r function. > This allows the code to behave within each thread as though that thread > were the only one. > > I don't think we should worry too much about how the replacements for > the statics behave *between* threads, because a threaded program > should really be using the _r functions. This was the rationale Microsoft gave for not supporting "Free Threading" until VC++ 4.2g, when they introduced the concept of Marshalling TSD (they call it TLS) between threads in nominally the same address space. I truly believe that this is the slippery slope. Unless the design issues are considered up front, we will end up with another historical crock, like library functions which return pointers to static data, or family specific network address manipulation routines, or VFS layers that make VM and other kernel specific calls, or TERMIOS tty revoke handling, or POSIX, etc.. Bogosities unfortunately abound. 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?199709181702.KAA20721>