>>>>> "Adam" == Adam Back <adam@xxxxxxxxxxxxxxx> writes: Adam> Hi Yes still here :) :) Adam> Give me a few days and I'll package up a new release with the Adam> current unintegrated patches. Great. I'll wait for the new release then. Adam> wrt to the two bits of code you wrote for parallel minting what Adam> are your thoughts? The C code I noticed you mentioned had some Adam> potential race condition/gap in collating results? I was thinking Adam> it would be fine to integrate it directly (with that issue fixed) Adam> as a new built-in feature. The python code I could put in the Adam> contrib directory? Thoughts on the python vs C? I wrote the Python code because I wanted to learn some Python. ;-) The race condition is solved by having each process write to a pipe, and having the master process read from each pipe. It's easier to do in Python than in C because in C you have to manage the buffers manually. Other than that, the corrected C code would look almost exactly like the Python code. I think the main trade off would be the difference between making the hashcash code more complicated, or having two different executables (and requiring Python for one of them). My opinion is that we should just go with the Python code for now, since it's already working, and decide if it's worth integrating the C code directly. Another possible solution would be to use threads instead of forking. It would probably run a bit faster, but probably not that much -- the bottleneck is the computation part anyways. But the main advantage is that we wouldn't have to use pipes, since the threads will share memory. The only thing that I'm not sure about is how portable something like pthreads is. i.e. is it available on Windows. -- Hubert Chan <hubert@xxxxxxxxx> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.