On May 21, 2008, at 3:27 PM, Karel Gardas wrote: > it's interesting how you spot the issue even w/o seeing the real > machine > here. Well, you are right.
;-) > Anyway, if you like to test anything on this broken "box", just let me > know and I'll test it for you Thank you! I do care about the issue of programs depending on a monotonically increasing gettimeofday when they do not need to. In my opinion it is one of those "insidious" issues that causes a problem so rarely that most people think it is okay. Looking around, I see that libcurl very recently started detecting and using CLOCK_MONOTONIC: http://article.gmane.org/gmane.comp.web.curl.cvs/9220 If you want to test darcs with a very recent libcurl, then I would be happy to gain confidence that darcs (and other libcurl-using programs) are not going to mysteriously hang if they hit the rare case that gettimeofday is not monotonically increasing. Hm. Except I just realized that I do not understand what happened on your system: > Interesting, so I used Solaris's pstack tool to print the stack of the > running process. What a cool tool. I wish linux had that. > It was quite strange to see all the threads ending on > something which should block and wait and see. So I executed pstack > several times and then seen that one thread is executing some call > from > curl and that the threads' top stack item is gettimeofday call. Does this mean that libcurl is in a fast polling loop, calling gettimeofday() over and over and using up CPU? Or that it is blocked in a system call that has not returned? Thanks! Regards, Zooko _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
