httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: SYSV Shared Memory (Was: Re: vote status)
Date Fri, 16 Feb 1996 12:39:35 GMT
David Robinson wrote:
> Jim Jagielski wrote:
> 
> >I've placed on ftp.apache.org in /httpd/patches/for_Apache_misc my
> >first rough-cut at using SYSV shared mem. It's called: shared_mem.patch
> >
> >This patch works, but I have some reservations about it. Mainly, the
> >fact that we call shmat() and allow the kernel to select the address to
> >place the segment and we keep the segment attached/mapped at all times.
> >This means that all subsequant(?) brk/sbrk calls will fail, as they
> >will refuse to move past an attached segment :(
> 
> Are you saying that shmat does _not_ attach the segment to the opposite
> end of the address space to the memory allocated by sbrk()? If so, then
> that _really_ sucks.

Yep... Although the exact location is OS dependent, and that some OSs
give more space between sbrk(0) and the mapped address, it does NOT
start at the upper end of the address space :(


Agreed.... that is incredibly, incredibly stupid.

> 
> Here's how it works with mmap() under Solaris
> (gdb) where
> #0  standalone_main (argc=3, argv=0xeffffa94) at http_main.c:1069
> 
> reinit_scoreboard = 0x0001862c    # static data from the executable
> pconf             = 0x00053058    # malloc memory from sbrk()
> scoreboard_image  = 0xef6f0000    # mmaped memory 'segment'
> &sa_server        = 0xeffff980    # dynamic data from the stack
> 
> So, from the top, there is the stack, which grows downwards and can use
> up to 8Mb, mmap()'ed memory, sbrk() memory, and static data from the
> executable text segment.
> 
> You must give it the address of _unallocated_ memory. Almost impossible
> to achieve.

Well... we could either do something like:

	/*
	 * Pick an address at the upper end of the address space
	 */
	address = ulimit(3, 0L) - STACKSPACE;
	shmat(id, address, 0);

-or-
	/*
	 * move sbrk(0) up a bunch; handle stupid values
	 */
	grow = EXTRASPACE;
	while (sbrk(grow) == -1)
	    grow /= 2;
	shmat(id, 0, 0);

In either case, it will be OS dependent (i.e. the value of STACKSPACE and
EXTRASPACE), but for the ugly, old SysV-based systems that lack mmap()
but need the extra performance, it may be a bullet to bite <grumble>
-- 
Jim Jagielski  << jim@jaguNET.com >>   |      "That's a Smith & Wesson,
  **  jaguNET Access Services  **      |       and you've had your six" 
      Email: info@jaguNET.com          |             - James Bond
++    http://www.jaguNET.com/         +++      Voice/Fax: 410-931-7060       ++

Mime
View raw message