Scheduler-friendly bcrypt NIF #12
Conversation
This commit splits the original bcrypt() fucntion into three separate NIF functions: bcrypt() - initializes the state for the Blowfish algorithm bcrypt_expandstate() - Blowfish_expand0state loop bcrypt_fini() - performs final encryption and returns hash There should be no change to the underlying algorithm.
Verified manually with the following method:
iex(1)> :erlang.system_monitor(self(), [{:long_schedule, 5}])
:undefined
iex(2)> spawn(fn -> Comeonin.Bcrypt.hashpwsalt("difficult2guess") end)
#PID<0.118.0>
iex(3)> flush()
:ok
iex(4)>
The number in the :erlang.system_monitor() call represents milliseconds. If an
erlang process ever uses up more than those milliseconds, a warning message
will be seen after the flush() call.
See: https://github.com/vinoski/bitwise#long-scheduling
|
Apparently, |
|
Great stuff! |
|
Please keep up the work on the Elixir implementation. If it performs efficiently, it will certainly be easier for yourself and others to maintain. There is a odd bug in 17.3 I had discovered thanks to Travis CI. I'm working on a fix. Edit: Filed a bug for this issue: #14. |
I have reworked the bcrypt C code to fix the issue seen in #8. These changes break up the longest running parts of the bcrypt algorithm in order to yield execution back to the Erlang VM every millisecond or so. I have verified the fix manually using the bitwise method.
There are a couple of concerns with these changes:
I see that you have started your own pure Elixir implementation of bcrypt. In the long run, that may be the best solution. In which case this code may be used as a temporary fix for #8, or you might want to pull it into a separate branch to compare the efficiency of the native code with a pure Elixir implementation when it is completed.
Thanks!