160724 - Rev test case for memory mapping and semaphores

Status: RESOLVED INVALID

(NSPR :: NSPR, defect, P5)

Description

[John Gaunt (redfive)]

We need the NSPR named shared memory and semaphores for the profile sharing
work. Need to make sure the code is working on all 3 main platforms.

Comment 1

[John Gaunt (redfive)]

Attachment: 1st pass at sem/mmap testcase cleaning

This modifies the ptsynch.c file to use SEM_UNDO and adds 2 new shared memeory
test cases. The first uses a single semaphore for the memory mapping ( unlike
the original test that used one per thread - 2 ) and the second writes
characters to test the ability of the OS to handle us writing over the end of
the memory to see if it will grow.

These have been run on Win2k sp2 and RH7.2 successfully, Mac OSX is next

Comment 2

[John Gaunt (redfive)]

For Mac the decision has been made to focus on mach-o compatibility to start (
this means Mac OSX will be support through the Unix apis ). If cfm support is
needed that will be added later ( would mean a carbon based layer would have to
be added to get at the Unix commands ).

Building mach-o now, should be able to test later this afternoon.

Comment 3

[John Gaunt (redfive)]

Attachment: new test case, for unix only

test developed on RH7.2 ( works ) to test MacOSX shared memory support. This
does a straigh fork(), unlke the nspr PR_CreateProcess() which does a
forkandexec(). Hopefully this will solve the problem...

Comment 4

[John Gaunt (redfive)]

Got the tests running on Mac OSX with some modification to the test. Need to
clean them up before finally posting them. 

It seems that we are going to need some way of testing the semaphore and shared
memory when we detach from them so we know if we can destroy them. I know there
is a call that will return the status for...I think it's SysV shared memory.
That way a process can tell if it is the last to be attached to the memory, and
then it can delete it. But I think we are going to need that functionality for
Win/POSIX/SysV semaphore and shared memory. This is the only way I can think of
for processes to know to delete these objects and premature deletion is Not
Good(tm).

Comment 5

[John Gaunt (redfive)]

Attachment: new test, XP

This test is made to be run mulitple times from the command line, to better
simulate the type of conditions we will see running multiple moz instances
(hopefully its more accurate).

Comment 6

[John Gaunt (redfive)]

Attachment: Better tests and diffed nspr stuff

This contains nameshm[2-5].c and the fixes needed for them. Does not include
the UNDO flag for the Unix systems, I'll roll that in when I test this patch on
Linux. Adds the nspr call PR_NumAttachedToSharedMemory to find out when
processes are finished with a specific named shared memory segment.

Comment 7

[John Gaunt (redfive)]

Attachment: reduced and cleaned up tests, including w/u/m stuff included

Comment 8

[John Gaunt (redfive)]

Wan-teh, could you look at the last patch. I've tested on Win2k, RedHat7.2, and
OSX (mach-o). Everything is working except for one slight problem on RH, which
really isn't a problem, but a side affect we have to work around ( when a
semaphore gets deleted you can't re-attach like you can on mac & win ) 

There doesn't seem to be a way to find out how many processes are still holding
on to a semphore in either POSIX or SYSV, like you can with SYSV Shared Memory (
nattach ), only how many processes are actually blocked on a semaphore.

I added to the NSPR api a method for finding out how many processes are attached
to shared memory. However, the only system that has an implementation is SysV.
POSIX doesn't have a way of getting that number, nor does windows but it seems
windows is much more leinient about re-attaching even after closing the shared
memory.

Comment 9

[John Gaunt (redfive)]

marking this as invalid, as the nspr code is not needed for profile sharing.