|
From: Julian S. <js...@ac...> - 2005-01-09 19:14:22
|
> Over the hols I decided it would be fun to rewrite Valgrind's
> syscall/threading stuff again.
>
> The basic idea came from Eric Estievenart [...]
That's great! I'm very pleased to see this. Especially losing 6600
loc sounds good to me.
> If people could try it out and see if it basically works for them, I'll
> check it in the next few days. In particular, I'd like it if the people
> considering porting Valgrind to other OS's could have a look and see how
> these changes affect them.
Before this goes in, I'd really like that
(1) support for 2.4, and particularly 2.4 on older systems (eg, your
2.4 on RH73) gets more beaten on and tested, since in reality we will
have to give good support for 2.4 for at least another two years.
(2) more regression test cases are fixed.
Are there any performance consequences that you are aware of? I had
some concern that programs which cycle rapidly between running threads
would be slower now, because each thread switch involves a trip into
the kernel where it didn't before.
> * Try to recover the lost pthreads functionality. All that
> pthreads API usage checking was useful, and it uncovered a lot
> of bugs.
Yes. That would be nice but is not critical. Perhaps a useful thing
to do at this point, assuming no nice-easy solution is available,
is to come up with a proposal which can be considered at length.
> * I implemented the thread-serializing run_sema with both a futex
> and a pipe-based token-passing scheme. The futex code is more
> efficient, but the pipe scheme works everywhere, so that's what
> is enabled by default. Switching is a compile-time option, but
> it could be done at runtime.
Do you have any numbers indicating the relative expenses of the two
schemes?
J
|