Re: Memory Issues

Peter Hunnisett wrote:
> At some point soon we'll be fixing that issue probably by allocating
> the size of the registry + some fixed amount. In order to do that,
> however, we need to move to a different manner of allocated shared
> memory.

POSIX shared mem (shm_open, shm_unlink) plus mmap() maybe?  (Yes, I may
have said this once before, but dang it, I like POSIX shared mem!  ;-) )

You could resize the shared segment with ftruncate() from inside the
wineserver.  Each process will have to re-mmap() it, though, to get
access to the larger size...  that might cause issues.

Maybe it would work to use one byte (or int, whatever) of the shared mem
as a flag to tell the other processes to re-mmap, and some type of
synchronization wait in a loop to block wineserver until each client
process has redone its mmap?  Maybe start a semaphore at 0, then have
each client up() it after redoing its mmap(), and have wineserver down()
it in a loop over each client?  That would work unless the clients use
the shared mem to talk to each other; in that case you'd have to use a
barrier to block them all until they were all done with the re-mmap().

Anyway, I'm just throwing out ideas here, as they come to me.

> You should be able to compile so that the shared memory is not used -
> look about line 31 of server/main.c and change the value of 
> shared_memory_server to 0. That should do the trick for the time
> being.

He might also be able to increase the size of the shared memory segment
that gets allocated -- at least, I was able to, without any ill effects
so far.  In server/shm.c, I changed the initial_size define from

#define initial_size (4*1024*1024)

to

#define initial_size (8*1024*1024)

and recompiled.

I haven't tried this on much of anything, but it does make my native
registry load successfuly when I run Sunbelt's Remote Administrator, at
least.