I got an excellent response on libMicro running on Mac OS X from the
darwin-kernel list at lists.apple.com, and in the spirit of open
communication I thought I'd share them here (he asked to be anonymous).
Firstly, a little more background on my efforts to get the full suite
to run on OS X. The following diff shows the elided tests such that I
wouldn't get any unavailable resource errors or test hangs:
$ diff Makefile.Darwin Makefile.Linux
42,50c42
< atomic \
< getcontext \
< setcontext \
< cascade_fcntl \
< cascade_flock \
< cascade_lockf \
< fork \
< exit \
< connection
---
> atomic
53c45
< include ../Makefile.com.Darwin
---
> include ../Makefile.com
So the cascase_* tests would give me the "resource temporarily
unavailable" error, but I also has issues with fork, exit and the
final connection test just seeming to hang.
Regarding the fork and exit hangs
> The exit and fork are hangs in their barrier operations assuming
certain POSIX semantics that we don't
> claim in our <unistd.h> settings, and which should have been
conditionalized on those settings. They
> have implementations for the Advanced Realtime Threads option,
which neither we nor Linux support,
> and they have an option for use of semop/semget/semctl in an
mmaped space using (incorrectly) IPC_PRIVATE.
> The correct implementation for our (or any IPC_PRIVATE) platform
would use semop() by way of semid -
> standards SystemV UNIX IPC, without the shared memory segment; if
you have to use shared memory from
> mmap() instead of shmget(), you'd need to use msync(), and the
IPC_PRIVATE might still kill you. The only
> use of msync() seems to be in the msync benchmark itself, which
implies a misunderstanding or at least
> some unjustifiable assumptions about the cache and memory
coherency model required for UNIX systems.
which does highlight the difficulty in writing a truly portable
microbenchmark. I must admit I was concerned with replacing the
reference to the realtime threads library to System on OS X (I was
merely following some advice on getting it to compile). What is
interesting is that apparently Linux doesn't support that library
either, although I haven't tested these on Linux.
And regarding the cascade_* tests my error wasn't able to be
reproduced, but
> I also got a CPU-eating infinite loop in cascade_fcntl(); it seems
the code takes a very long time to run.
> I think it also has a misunderstanding of the use of semop(), and
it also seems to have an issue with
> overall fcntl-based file lock semantics (perhaps it would have
completed had I been more patient). As
> far as I can tell, it never hits a hard limit there.
>
> I had no problems getting actual results from cascade_flock and
cascade_lockf.
This gets me nowhere with my error though. Perhaps it could be
architecture related. I'd reproduced these errors on two G4 systems,
and he had them running on a G5 and G3 system. It does seem unlikely
that architecture could influence the amount of file locks the OS is
willing to create though.
I'd love to hear everyone's thoughts on this.
Cheers,
Ben
On 12/08/2005, at 6:28 AM, Dan Price wrote:
On Thu 11 Aug 2005 at 11:56AM, Eric Saxe wrote:
This might sound dumb, but are we sure that processes are the
resource
which is temporarily unavailable?
I think what you are saying, Dan, is that "this might be so
obvious that
it has escaped you", and you very well might be right. :)
The reason I ask is IIRC these were test cases about file locks:
...
Running: c_lockf_10 for 0.50919 seconds
Running: c_lockf_200fork: Resource temporarily unavailable
Running: c_flockfork: Resource temporarily unavailable
Running: c_flock_10fork: Resource temporarily unavailable
Running: c_flock_200fork: Resource temporarily unavailable
Running: c_fcntl_1fork: Resource temporarily unavailable
Running: c_fcntl_10fork: Resource temporarily unavailable
Running: c_fcntl_200fork: Resource temporarily unavailable
I recently had a discussion with Devon O'Dell about how MacOS has
limited
the number of these that the OS is willing to create. Based on that
conversation I opened an RFE:
6293764 RFE: resource control governing file range locking
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6293764
Thanks,
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] -
blogs.sun.com/dp
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
Ben Cooper
Quality Control Analyst
Whitesmiths Pty Ltd
Tel: +61 2 8912 1774
Fax: +61 2 8912 1701
Email: [EMAIL PROTECTED]
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager. Please note that any views or opinions presented
in this email are solely those of the author and do not necessarily
represent those of Whitesmiths. Finally, the recipient should check
this email and any attachments for the presence of viruses.
Whitesmiths accepts no liability for any damage caused by any virus
transmitted by this email.
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
