Re: Memory Issues

Bryan Kadzban wrote:

> 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!  ;-) )

Well we'll have to look into a couple of approaches for getting a 
sufficient set of memory. Patches welcome preferably those that do 
runtime checking of functionality ;)

>
> 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.

The fundamental issue is that is required is that each process needs to 
ensure that they are able to safely switch to a new area. It's already 
bad enough to have a hard coded address in my mind but the danger is 
that one process, for some reason, can't increase the size.

This wouldn't be a problem if all data was stored self relative because 
it could be mapped anywhere in different processes address space, but 
that's a big can of worms that's non trivial to address.

>
> 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().

The wineserver can't wait for a client to call into it and the 
wineserver as a rule can't push data to the client so that doesn't work. 
It's, however, possible to just check on each entry into the shm 
wineserver if your values match the master set assuming the master set 
is in a non changing location. The check is quick enough but the problem 
is if the process cannot allocate the new area.


>
> 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.
>
Ciao,
Peter