Ben Cooper wrote:
Interestingly when I ran the cascade_flock 200 test manually I got the resource temporarily unavailable fork error straight away, so I don't think it's libMicro not waiting for the processes of previous tests to run. When I tried putting the kern.maxproc and macprocperuid as high as it would go (2068 seemed to be it's hard limit), the same behaviour occurred.
As an aside, another issue with things like cascade_flock pops up in the multithreaded cases (i.e. with the -T option instead of -P) ... because the locks are considered owned by the process, not by the thread.
On 10/08/2005, at 10:37 PM, Phil Harman wrote:And it is portable! We've had it running on Solaris (all platforms, both 32-bit and 64-bit), Linux, AIX, HP-UX, MacOS X, and Windows XP (using Microsoft's own Services For UNIX as well as the Cygnus environment). However, some of these needed quite a lot of hand crafting, and we didn't have time to tidy up our Makefiles sufficiently to include more than SunOS, Linux and AIX.Because of my above issues with OS X, I put cascade_fcntl, cascade_flock and cascade_lockf in the elided benchmark list in the makefile. This seemed to do the trick with the fork error, but then it hung on the fork_100 test. OSX definitely doesn't like these fork tests! I'll put this in the elided list and try again, if only for the purpose of getting most of the tests running. Can you let me know what changes you made to get OSX working internally?
I don't know if I still have the stuff (otherwise, I would have volunteered it at the time). I think we had quite a few elided cases. If I can find anything, I'll post it. Interestingly, one of the easiest ports was when I tried Windows SFU (much closer to POSIX than the Cygnus stuff).
Phil
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ perf-discuss mailing list [email protected]
