Re: single task postgresql - Mailing list pgsql-hackers

mlw wrote:
> Greg Copeland wrote:
> 
>>Windows does not really have shared memory support.  This has been a
>>beef with the Win32 API for a long time now.  Because it has been a long
>>time complaint, it was finally added in Win2000 and later.  Likewise,
>>I'd like to point out that thinks like sims, shared memory, pipes, etc,
>>and other entities commonly used for concurrent programming strategies
>>are slower in XP.  So, because shared memory really isn't well
>>supported, they elected to have what is, in essense, memory mapped
>>files.  Multiple processes then map the same file and read/write to it
>>as needed, more or less as you would shared memory.  Unless you plan on
>>only targetting on Win 2000 and XP, it sounds like a waste of time.
>>
> 
> This is not really true. Under DOS windows, i.e. 95,98, etc. Shared memory can
> be done in 16 bit land with a touch of assembly and a DLL. Allocate, with
> globalalloc, a shared memory segment. The base selector is a valid 32 bit
> selector, and the memory is mapped in the above 2G space shared and mapped to
> all 32bit processes.


That's fine ad all, however, we're talking about the Win32 API.  None of 
that qualifies.  If you wish to implement back door magic for your own 
use, I guess that's fine but I'd wonder how well it would be received by 
the rest of the developers at large.  I'm betting it wouldn't give me 
the warm fuzzies.

> 
> Under NT through 2K, yes using a memory mapped files is the way to do it, but
> you do not actually need to create a file, you can use (HANDLE)0xFFFFFFFF,
> which is the NT equivilent of the system memory file. The handle returned is a
> system global object which can be shared across processes.
> 

Yes, that's fine, however, this pretty much puts us back to a memory 
mapped file/shared memory implementation.

I guess you could have a feature set which is perhaps optimial (again, 
I've not seen anything which indicates you'll see perf improvement) for 
Win2000/XP platforms.  Perhaps you'd be willing to perform some 
benchmarks and provide source of random read/writes to these segments 
and present to us for comparsion?  I'm personally very curious as to see 
if there is any addition speed to be gleaned even if I am doubtful.

On a side note, if you did create such a benchmark, I'm fairly sure 
there are a couple of guys at IBM that may find them of interest and 
might be willing to contrast these results with other platforms (various 
win32 and unix/linux) and publish the results.

After all, if this path truely provides an optimized solution I'm sure 
many Win32 coders would like to hear about it.

Greg