Re: next release?

>>>>> "Adam" == Adam Back <[email protected]> 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 <[email protected]> - 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.