Menu
▾
▴
firebird-devel
|
From: Pascalis <sa...@ma...> - 2004-04-15 17:37:34
|
I have the following questions regarding 64 bit Firebird (using 64 bit handles). Can a 32 bit application running on a 32 bit client computer connect to a 64 Firebird server ? Can a 32 bit (compiled) application running on a 64 bit system connect to 64 Firebird ? |
|
From: Jim S. <ja...@ne...> - 2004-04-15 18:06:46
|
Pascalis wrote: >I have the following questions regarding 64 bit Firebird (using 64 bit >handles). > >Can a 32 bit application running on a 32 bit client computer connect to a 64 >Firebird server ? > Yes >Can a 32 bit (compiled) application running on a 64 bit system connect to 64 >Firebird ? > > Yes and no. A 32 bit client can call a 32 bit remote interface that talks to a 64 bit server. It can't link directly to a 64 bit database engine for embedded use. In theory it could with a "thunking" library, but I don't think any of the hybrid 32/64 bit systems actually support this. Vulcan is designed to support simultaneous 32 and 64 processes on a hybrid platform for central server and embedded use with a single install and combined configuration files. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
|
From: James K. L. <jkl...@sc...> - 2004-04-16 01:31:40
|
On Thu, 15 Apr 2004, Jim Starkey <ja...@ne...> wrote: > >Can a 32 bit (compiled) application running on a 64 bit system connect > >to 64 Firebird ? > > > Yes and no. A 32 bit client can call a 32 bit remote interface that > talks to a 64 bit server. It can't link directly to a 64 bit database > engine for embedded use. In theory it could with a "thunking" library, > but I don't think any of the hybrid 32/64 bit systems actually support > this. > > Vulcan is designed to support simultaneous 32 and 64 processes on a > hybrid platform for central server and embedded use with a single > install and combined configuration files. Finally, it's clear to me. Some newer (not Alpha or Sparc) 64-bit architectures support 32- and 64-bit addressing modes in a single process. On such a chip, a 32-bit clients won't be able to link safely to an embedded 64-bit server, because their definitions of void* differ. Is that it? If I understand you correctly, a 32-bit executable could link to a 64-bit shared object, blithely unaware that their pointers are different sizes. It that really true? Because, if so, it would be a much bigger problem than our one little handle. How, for instance, would such a pair exchange file handles, which POSIX defines as a pointer to a "structure containing information about a file"?[1] Why would anyone choose to run this kind of mixed model, when he could just recompile one or the other module? If it's advantageous to run a 32-bit client and a 64-bit server on the same machine, would it be just as well to force them to use a remote interface instead? --jkl [1] http://www.opengroup.org/onlinepubs/007904975/basedefs/stdio.h.html |
|
From: Jim S. <ja...@ne...> - 2004-04-15 18:08:20
|
Pascalis wrote: >I have the following questions regarding 64 bit Firebird (using 64 bit >handles). > >Can a 32 bit application running on a 32 bit client computer connect to a 64 >Firebird server ? > Yes >Can a 32 bit (compiled) application running on a 64 bit system connect to 64 >Firebird ? > > Yes and no. A 32 bit client can call a 32 bit remote interface that talks to a 64 bit server. It can't link directly to a 64 bit database engine for embedded use. In theory it could with a "thunking" library, but I don't think any of the hybrid 32/64 bit systems actually support this. Vulcan is designed to support simultaneous 32 and 64 processes on a hybrid platform for central server and embedded use with a single install and combined configuration files. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
|
From: Jim S. <ja...@ne...> - 2004-04-16 03:10:50
|
James K. Lowden wrote: >Finally, it's clear to me. Some newer (not Alpha or Sparc) 64-bit >architectures support 32- and 64-bit addressing modes in a single process. > On such a chip, a 32-bit clients won't be able to link safely to an >embedded 64-bit server, because their definitions of void* differ. Is >that it? > In theory, yes, in practice, I think not. Both the Ultra-sparc and AMD64 support 64 bit with additional instructions leaving the original instruction set unchanged. But doing so is chaos as the calling sequences are different. I may be wrong, but I believe that neither the linkers not dynamic loaders allow mixing of 32 and 64 bit modules. I don't know whether the OS knows whether the process is 32 or 64 bit, but I think it's moot since mixing doesn't work. The system services have to be 64 on hybrid systems, requiring a thunking front end for 32 bit processes. Interesting enough, Solaris compilers and linkers default to 32 bit while Fedora defaults to 64 bit. This is probably more whim than anything else. But very, very few use processes benefit from > 32 address space. This will grow, but most problems aren't that hard. The exceptions justify the architecture, however. Firebird doesn't know what to do with a large address space. Hint: page cache isn't the answer. For fixed resources, a mix of most 32 bit process and the few 64 bit process that can benefit is probably the right answer. Time, presumably, will tell. > >If I understand you correctly, a 32-bit executable could link to a 64-bit >shared object, blithely unaware that their pointers are different sizes. >It that really true? Because, if so, it would be a much bigger problem >than our one little handle. How, for instance, would such a pair exchange >file handles, which POSIX defines as a pointer to a "structure containing >information about a file"?[1] > Doesn't work at all. The unit in all calling sequences has to be the address length, so mixing 32 and 64 bits is never going to work without a lot of effort. >Why would anyone choose to run this kind of mixed model, when he could >just recompile one or the other module? > 32 bit processes are much smaller, so you get more processes per unit of memory. But memories are bigger (the smallest 32 bit machine I've seen offered for sale is 512MB, which used to be a huge honkin' hunk of memory). >If it's advantageous to run a 32-bit client and a 64-bit server on the >same machine, would it be just as well to force them to use a remote >interface instead? > > It's highly application specific. For many applications, a huge number of embedded engines is the way to go. Until the thread stack space is blown, 32 bits looks attractive. When you start to put the 32 address space limites, 64 bits is the escape, but each stack does double in size. Heap bloats less, but not by a lot. Thinking about it leave me with a headache. The solution is an easily configurable system and a stop watch. Reality trumps speculation every time. |
|
From: James K. L. <jkl...@sc...> - 2004-04-16 22:30:47
|
On Thu, 15 Apr 2004, Jim Starkey <ja...@ne...> wrote: > >Finally, it's clear to me. Some newer (not Alpha or Sparc) 64-bit > >architectures support 32- and 64-bit addressing modes in a single > >process. > > On such a chip, a 32-bit clients won't be able to link safely to an > >embedded 64-bit server, because their definitions of void* differ. Is > >that it? > > > In theory, yes, in practice, I think not. Both the Ultra-sparc and > AMD64 support 64 bit with additional instructions leaving the original > instruction set unchanged. But doing so is chaos as the calling > sequences are different. I may be wrong, but I believe that neither the > > linkers not dynamic loaders allow mixing of 32 and 64 bit modules. I > don't know whether the OS knows whether the process is 32 or 64 bit, but > > I think it's moot since mixing doesn't work. Thanks for clearing that up. Now I definitely don't understand what all the hullabaloo is about. Do you have a technical this-won't-work issue, or a political this-won't-fly issue, or an aesthetic this-won't-do issue? From everything you've said, there's no possibility (as of now) of a 64-bit and a 32-bit process exchanging pointers to anything. Neither, supposing it were possible, is there any clear circumstance under which that would be advantageous. Where I come from, when the implementation and the documentation are at variance, and there's no functional problem, it's usually best just to update the documentation. > If you were thinking of spending your weekend getting up to speed on the > latest in Vulcan, may I suggest that your time would be more fruitfully > applied to going outside smelling the flowers? Aye, good advice. But you will be missing the first blessings of Spring, sir. --jkl |
Thanks for helping keep SourceForge clean.
X