Received: from localhost (IDENT:root@hectic-3.jpl.nasa.gov [128.149.68.205]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA63571; Wed, 10 Nov 1999 10:37:01 -0500 (EST) (envelope-from lockhart@alumni.caltech.edu) Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1]) by localhost (8.8.7/8.8.7) with ESMTP id PAA10568; Wed, 10 Nov 1999 15:43:46 GMT Sender: lockhart@hub.org Message-ID: <382992B2.86C9C99F@alumni.caltech.edu> Date: Wed, 10 Nov 1999 15:43:46 +0000 From: Thomas Lockhart X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: The Hermit Hacker CC: phd2@earthling.net, PostgreSQL-development , pgsql-interfaces@postgreSQL.org Subject: Re: [HACKERS] CORBA STATUS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > See...I am interested, just not interested in having us tied to one > "vendor"...:) I know. That still doesn't keep me from being in a bad mood after spending 3.5 hours at the dentist yesterday :(( On the Corba fork vs thread issue: It is true that the server process would need to be handed off to the client in a different manner from the postmaster; with Corba you don't just fork onto a different port and be done with it. However, the postmaster *could* start up a server process and return an IOR to the client, which givs the client a direct handle to the server. The client would then initiate contact directly with the server, and the postmaster is no longer involved. afaik you could still fork in the postmaster, though whether our streamlined tricks would work with every Orb is not certain. But that is an optimization for our specific forking implementation, not a fundamental feature. As I mentioned, the real performance benefits come from having an optimized query connection which bypasses the *expensive* string conversions we currently use to pass data around. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California