We have a third party library (which we do not have the source for), that calls getpid() everytime it logs something. Unfortunately, in the application where the library is being used, this results in over 4000 getpid calls/sec (accounting for over half the total system calls/sec being made by all the threads in the application), causing performance issues under high load.
While we are working with the vendor to see if they can deliver a fix, I'd like to have a plan B. Since the application itself forks very infrequently, I was thinking of interposing getpid() and caching the results upon first invocation. I was curious if anyone has any comments about potential pitfalls of doing this. The only things I can think of is possibly needing to also interpose fork(), fork1(), and forkall() to essentially reset the cached pid value so on next invocation (in either child or parent to hopefully make it easier) it'll just regrab the pid value and cache it. The only other thing is potential thread safety -- I'm not sure if assignment to pid_t or a pointer is atomic or not (or if I'd need to utilize the atomic_ops instructions). Any thoughts? This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
