Date: Tue, 16 Jul 2002 19:56:29 -0500 From: Jordan DeLong <fracture@allusion.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: Taavi Talvik <taavi@uninet.ee>, freebsd-chat@FreeBSD.ORG Subject: Re: Linker sets portability Message-ID: <20020717005629.GA42607@allusion.net> In-Reply-To: <3D34AC52.2D882455@mindspring.com> References: <20020717014008.Y99892-100000@valu.uninet.ee> <3D34AC52.2D882455@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Somewhat tangential, so going to -chat. On Tue, Jul 16, 2002 at 04:29:22PM -0700, Terry Lambert wrote: > Taavi Talvik wrote: > > Probably this belongs to questions, but anyway: > >=20 > > How portable is idea of using linker sets? Is it possible > > to use them (maybe using some preprocessor wizardry) on > > linux/solaris/win/etc? Do they have somewhat similiar facilities? >=20 > "Moderately portable". >=20 [ ... ] > Microsoft DLL's have that ability, derived from OLE, and based on > the current COM (Common Object Model) to create arbitrary support Component object model actually, I believe. > for aggregate objects. Specifically, Microsoft DLL's which are > instances of COM objects generally have "process attach" and > "process detach" entry points (equivalent to ".init" and ".fini" > in UNIX for the creation of global constructors and destructors). >=20 > They also have the ability to support arbitrary "thread attach" > and "thread detach" entry points. These are necessary to be able > to support "rental" and "apartment" model threading, which permits > you to create a thread-unsafe library, and maintain the ability to > use it from a threaded program anyway (UNIX is very behind Microsoft > here; an example is the LDAP and IMAP4 client libraries, both of > which could benefit from these models, but of course, the LDAP > libraries are generally not thread safe even on Win32, because > people don't know how to program to Windows threads models). If you spend a few moments playing with COM, you'd probably realize that the COM threading models are so painfully braindead it's not even funny (and they're a symptom of the rampant misuse of threading found in win32, not a sign of win32 being ahead of unix).=20 Basically if you want to use more than one appartment in the same process, you're going to have trouble (and keep in mind this is the whole theoretical point of the threading models): Because calls into the STA from other appartments are implemented by using a hidden "COM Window" and packaging every call into a windows message, anytime you enter a modal message pump from the main STA another thread can renter the STA's objects -- and there is *no* way to effectively lock them out as one would normally do in an MTA app because it's the same physical thread, even though it is a different "logical" thread (i.e. it would own any critical section objects already, etc). This behavior is entirely unpredictable and unavoidable, because you have no control over the internals IMessageFilter can't solve the problem, but i'm getting off track) of modal message pumps (which exist in several apis). OTOH if you put stuff into the MTA and try to access other pieces in an STA which may call back into it (the mta), win32 will actually spawn a new thread for every method call back into the MTA. So that's gross, but it's worse than just gross: because this is a differen't physical thread (but the same "logical" thread, if you take my meaning) it can't recurse on mutexes. I don't see why the win32 people couldn't have just done their component thing without regard to threading, and let individual app/component writers deal with it. It's just trying to solve too many (nonexistant) problems with one architecture (for more of this see their new COR/CLR/.NET (whatever it's called this week) replacement for COM+). [ ... ] > So the general answer is "pretty much everyone whose linker is > capable of linking programs compliant with the C++ standards, > and whose C compiler supports a sufficiently sophisticated ability > to escape to inline assebly to generate the data that the linker > uses to accomplish C++ specific features, can be made to support > linker sets". OT: (This isn't important to the point you were making... but then again neither was the COM stuff above :P). I don't think a truely standards compliant C++ compiler exists... neither G++ nor MSVC++ comply to the standard completly.. --=20 Jordan DeLong fracture@allusion.net --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9NMC7DrrilS51AZ8RAhOfAKCZ8ESmO/U5D4EcZDJFFqg9SFNrRACdGENj ZC3PP99gM7aYrxQYOEXwu4E= =gH93 -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020717005629.GA42607>