royaltm / node-murmurhash-native

MurmurHash native bindings for node
MIT License
48 stars 7 forks source link

Question: Using the async interface #11

Closed jodevsa closed 6 years ago

jodevsa commented 6 years ago

Hello @royaltm ,

Could you elaborate on this: Be carefull as reading and writing by multiple threads to the same memory may render undetermined results

What i understood is that invoking a hash functions in parallel ie: without waiting for the first callback, could be a problem?

Thank you for your work!

royaltm commented 6 years ago

It means you can't do something like this:

var mm = require('murmurhash-native/promisify')();
var output = Buffer.alloc(4);
Promise.all([
  mm.murmurHash32Async('foo', output),
  mm.murmurHash32Async('bar', output),
  mm.murmurHash32Async('baz', output),
]).then(() => {
  /// the content of output is undetermined
})

but if you reserve a separate space for output of each concurrent task it's ok:

var mm = require('murmurhash-native/promisify')();
var output = Buffer.alloc(12);
Promise.all([
  mm.murmurHash32Async('foo', output, 0),
  mm.murmurHash32Async('bar', output, 4),
  mm.murmurHash32Async('baz', output, 8),
]).then(() => {
  console.log(output.slice(0,4))
  console.log(output.slice(4,8))
  console.log(output.slice(8,12))
})
jodevsa commented 6 years ago

excuse my noobiness! but what about using the async interface without providing a buffer? would that create a new buffer for each call and hand it back; if called with 'buffer' param ?

Thanks for your reply

royaltm commented 6 years ago

Sure. The problem arises only when you provide and re-use a previously created buffer. When you don't then each time the new buffer is being created for the hash output so no race condition is possible. But creating a buffer each time is slower than re-using a pre-created one.

jodevsa commented 6 years ago

Thanks alot :+1:

royaltm commented 6 years ago

You are welcome :)