I'm planning to require a UUID in the pbc header which would make each
pbc distinguishable from every other pbc. This would have no privacy
issues if it's done right, because the pbcs are identified, not the
parrot installations that create them.
Any problems here? Any suggestions for UUID code that's licensed
appropriately for use in Parrot?
--
Chip Salzenberg <ch...@pobox.com>
i know mod_parrot would benefit from this. one question though -- if a
redundant UUID is found, will the internals make the decision to load/not
load or will that be up to the HLL/embedding code?
> --
> Chip Salzenberg <ch...@pobox.com>
>
-jeff
The internals would make the decision. Speaking Perl 5 momentarily, the
semantics would be like 'require' rather than 'do'.
--
Chip Salzenberg <ch...@pobox.com>
Hey, neat.
On the other hand, the idea has been raised on IRC (by Joshua, IIRC)
that an MD5 or SHA256 would protect against corruption, and would also
incidentally make a dandy UUID.
--
Chip Salzenberg <ch...@pobox.com>
was there any discussion about what the checksums would be calculated on?
one benefit of UUIDs is that they are usually independent of the
underlying data they identify, and would therefore have no performance
penalty for larger files. i know it's only a one-time hit for PBC files,
and a minor one at that, but does this also apply for evals/compiles?
-jeff
I don't see a point in using it for evals/compiles.
As for the pbc file case: If you're making a pbc so large that hash
creation takes noticeable time, then just imagine how long _writing_
it will take? :-)
--
Chip Salzenberg <ch...@pobox.com>
> On Tue, Oct 18, 2005 at 11:27:16AM -0400, Jeff Horwitz wrote:
> > On Tue, 18 Oct 2005, Chip Salzenberg wrote:
> > > On the other hand, the idea has been raised on IRC (by Joshua, IIRC)
> > > that an MD5 or SHA256 would protect against corruption, and would also
> > > incidentally make a dandy UUID.
> >
> > was there any discussion about what the checksums would be calculated on?
> > one benefit of UUIDs is that they are usually independent of the
> > underlying data they identify, and would therefore have no performance
> > penalty for larger files. i know it's only a one-time hit for PBC files,
> > and a minor one at that, but does this also apply for evals/compiles?
>
> I don't see a point in using it for evals/compiles.
>
> As for the pbc file case: If you're making a pbc so large that hash
> creation takes noticeable time, then just imagine how long _writing_
> it will take? :-)
this answers my question. :)
-jeff
Also keep in mind that on modern hardware most hash algorithms are IO
limited. If you just wrote that file out to disk at least parts of it
are likely to be either buffered in the VM or cached there so the time
spent actually hashing the file (for large files) should be less then
the ammount of time it takes to physically write the file to disk.
Cheers,
-J
--