Re: [Valgrind-users] [NRR] RedHat 8.0 pthread "problem"

[Dan K. <da...@ke...>]

Beau D. Simensen wrote:
>>I have to ask -- why are you using threads here?
>>What you've described would work well, and would
>>scale better, using nonblocking i/o and sys_epoll...
> 
> [NRR] - I wanna answer 'cus I think I can get some good input from some of
> ya'll, but this response post really isn't valgrind related.
> 
> The short answer? Because I was unable to find a good reference to base my
> code off of? =) As I said, I'm more of a Perl guy, and I have never really
> done much with sockets before either.   ...
 > [description of daemon acting as both client and server, issuing and
 >  serving both long and short requests]
> To be honest, I really can't even begin to imagine how to do this without
> threads, and I certainly can't imagine it being easier to implement and
> manage any other way. But I'm new... =) *any* help on this would be greatly
> appreciated though. If I saw a great reference as to how someone is doing
> something similar w/o threads, I might just jump on it.

You can most definitely do this all without threads, but it's a big
change in how you think about things.  Worse, if you have to do
anything like disk I/O or use a subroutine library somebody else
wrote that uses blocking I/O, getting away from threads is even harder.

One of these days, I hope somebody publishes a few good examples of
how to do the kind of complex system you're talking about using
nonblocking I/O.  I've written several such systems, but haven't had
the time to document the kind of framework you need.  The closest I've
come so far is to write http://www.kegel.com/c10k.html.

Getting back to valgrind and thread problems, I have a reverse Heisenbug in OpenOffice
under valgrind.  If I run openoffice under gdb and do a File/Save As,
it aborts when I press the first keystroke of a filename.  The stack
traceback is from select(), which seems odd, and there are no threads.  Hmm.
If I run under valgrind, no such problem; File/Save As works fine.
I wonder if this is because I'm running on a dual-processor machine,
and the problem is a clash between threads.
Since valgrind causes all the threads to run on the same simulated cpu,
it can't really observe that whole class of bugs.  You don't happen
to be on a dual processor machine, do you?
- Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045