On Mon, Jul 18, 2011 at 10:32 AM, John Reiser <[email protected]> wrote: >> Is there a reason for assuming that syscalls won't block by default? > > There is substantial overhead to allow for the possibility that a syscall > might block. This wakes up valgrind's internal machinery for threads, > which is not spry. chdir and fchdir are used infrequently enough that > it might not matter too much; but stat64 and close are used quite often.
Ok, makes sense. Tom Hughes suggested that I create a bug and attach my patch, so that's what I did. If it is going to be a significant performance hit, maybe it would be better to have an option that can turn this on for all syscalls? That way when debugging a fuse file-system, the syscalls won't deadlock, but it won't slow things down for the general user. Also I imagine there are other filesystem related syscalls that would have the same issue - I only patched the ones that were causing me trouble. Thanks for the help, -Mike ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
