httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@ast.cam.ac.uk (David Robinson)
Subject Re: SYSV Shared Memory (Was: Re: vote status)
Date Fri, 16 Feb 1996 12:01:00 GMT
>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
>
>It's got some limitations due to the way it's implemented, but it's
>working. It might be a good starting point.
>
>This is what I wrote at the top of the patch:
>-------
>This patch file is a first cut attempt to implement SYSV shared-memory
>for Apache. This patch assumes that the MMAP patch is installed and is,
>in fact, against the apache_1.0.2_patched tree.
>
>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.

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.

>A coupla ideas to get around that:
>
>   1) Just shmat() when needed and then detach. We can treat the
>      shared segment as an external "file" in other words... This is
>      ugly and not as clean as the mmap() method where we can simply
>      write to scoreboard_image (this idea would be implemented as
>      the scoreboard_image array and a pointer, scoreboard_shared,
>      to a segment. When we change scoreboard_image, we attach
>      scoreboard_shared, copy to the segment and then detach...

Yuck.

>   2) Figure out a way to use the "give shmat() an actual address to
>      use as the 2nd parameter in the system call"... I haven't
>      been able to figure this out yet... I allocated a chunk of
>      space and use a pointer to it as the value, but shmat() fails
>      with an Invalid Parameter error... Maybe because the allocated
>      space is < a segment size ????
>
>    3) Before we call shmat(), call sbrk() and move 'end' "way up there"...
>       Ugg.

You must give it the address of _unallocated_ memory. Almost impossible
to achieve.

 David.

Mime
View raw message