On Sat, Mar 1, 2008 at 2:04 PM, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> Dominique Pelle wrote: (...snip...) > > I have to say that setting up a timeout for waitpid() in a portable way > > is a tad complicated and ugly: 3 different ways for various flavors of > > Unix + another way for non Unix. I tried to make it as portable > > as possible. If SIGALRM is not defined, it does not used timeout. > > > > Perhaps the code using sigvec() is not needed? i.e. either use > > sigaction() on Linux or signal() on other Unix flavors. That would > > simplify a bit but I don't have the machine to test it. > > Why don't we use two methods: When sigaction() is available use that, as > in your first version of the patch. When it is not available then make > a loop that sleeps for a very short moment (e.g., 50ms, using > mch_delay()) and checks if cscope still runs. Break the loop after 2 > seconds or when cscope has quit. That should be very portable. > > See the proposed patch below, please try it out. I removed SA_NOMASK, my > system doesn't have it. I think SA_NODEFER is used instead. But can we > leave this one out completely? Yes, it looks simpler. Using asynchronous SIGALRM is better of course. But when it's not possible, polling is a pragmatic and portable fallback. I can't try it because I'm away until next week. I see 2 refinements: - If waitpid() returns -1 (error), the loop will currently retry 40 times. I think this is a useless delay of 2 seconds. It's better to break the loop immediately if waitpid returns -1. In other words: when pid == 0, sleep 50ms and retry when pid > 0 exit loop (normal case when cscope finishes) when pid < 0 error, break loop and revert to kill cscope. - I think with the proposed patch, Vim will almost always wait at least 50ms, because cscope did yet get a chance to be scheduled before Vim calls the first unblocking waitpid(). So first call to waitpid() will always return 0, and Vim will then always call mch_delay(50) at least once (giving then a chance for cscope to be scheduled) and second call to waitpid() is then likely to return > 0. This may always add a small unfortunate delay (but no much) when exiting Vim. If we add a sleep(0) before first call to waitpid() to yield the CPU, it will give more chance for cscope process to grab the CPU and thus respond to the q command before Vim calls waitpid() for the first time. So the first call to waitpid() has more chance to return with pid > 0, hence possibly avoiding a sleep of 50ms. Of course they is no guarantee, but it can only help I think. Sorry, I can't provide a patch with this as I am away until next week and I only have a webmail access. > > > > PS: different topic: file src/testdir/test42.ok is still corrupted in > CVS > > > > > > Hmm, I thought I fixed it with: > > > cvs ... admin -kb src/testdir/test42.ok > > > What else can I do? > > > > Revision 1.2 looks corrupted somehow. Whether it was because of > > CVS -kb option, I'm not sure. In any case, since it's a binary file, it > > was better to set -kb option. How about checking it out and commiting > > the pristine version again as revision 1.3? > > Ah, the copy of the file was already corrupted locally. Must have been > because "patch" failed on this file. Sorry for blaming CVS. Thanks, I will check this when I'm back. Cheers -- Dominique --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
