paulthetafy,
The reasons for this segmentation fault is that I am modifying the Block pointer each thread contains by the connection thread, and sometimes they go out of sync. This can be fixed with a faster autoptr or even using more sophisticated locks than my boolean flags.
I'll get to fixing this, I'm thinking for now I'll just release another code base that has one connection per thread, which would eliminate this issue. The Mining LLP can definitely handle it.
As to your question, you'll see in the main function when the Server Connection is declared, it has an argument for how many threads. The Mining Thread class is then instantiated in a vector to the quantity you declare with the commandline arguments that is passed into the Server Connection class constructor. The connection class [with a bound thread] then handles each of the mining threads, modifying the flags if a new block is found on the network, or submitting blocks if the thread sets its fBlockFound flag. This is the optimal way I would like to do it, but will take a little more time with the proper locking techniques to eliminate the segmentation fault [which comes from accessing a memory location not allocated by the operating system for that specified process].
Thank You,
Viz.
The reasons for this segmentation fault is that I am modifying the Block pointer each thread contains by the connection thread, and sometimes they go out of sync. This can be fixed with a faster autoptr or even using more sophisticated locks than my boolean flags.
I'll get to fixing this, I'm thinking for now I'll just release another code base that has one connection per thread, which would eliminate this issue. The Mining LLP can definitely handle it.
As to your question, you'll see in the main function when the Server Connection is declared, it has an argument for how many threads. The Mining Thread class is then instantiated in a vector to the quantity you declare with the commandline arguments that is passed into the Server Connection class constructor. The connection class [with a bound thread] then handles each of the mining threads, modifying the flags if a new block is found on the network, or submitting blocks if the thread sets its fBlockFound flag. This is the optimal way I would like to do it, but will take a little more time with the proper locking techniques to eliminate the segmentation fault [which comes from accessing a memory location not allocated by the operating system for that specified process].
Thank You,
Viz.
Thanks Viz, I'll see if I can put a simple mutex in to synchronize access to the BLOCK between the threads. If I get that working I'll shoot you the update.
Still not sure I understand how each thread is not doing the same "work" though. Are they looking for different nonce's??
