search

bgamari / nanomsg-haskell

Haskell bindings to nanomsg
MIT License
25 stars 12 forks source link

Updated tests & converted unsafe calls to safe ones #5

Closed buckie closed 9 years ago

buckie commented 9 years ago

I changed unsafe calls to safe for better runtime system interaction - so we can use the bindings with multithreading and not lock the world. This was at the behest of @cartazio so he may have more comments on why. Was there any specific reason not to use safe for the FFI? I was unable to find one in the docs but could have missed something.

Also, I updated the tests so that they would build. Not sure what changed to cause them to not build thought I think it is due to me using 7.10.

ghost commented 9 years ago

I changed unsafe calls to safe for better runtime system interaction - so we can use the bindings with multithreading and not lock the world.

Sounds reasonable. I'll upload a new release to Hackage within a day or two. I will squash the "removed tags" commit, if you don't mind.

Was there any specific reason not to use safe for the FFI?

The C API is non-blocking. The only "blocking" functions, recv and send, are handled asynchronously by the runtime using threadWaitRead and threadWaitWrite. Given that, locking the world to avoid some overhead seemed fine to me.

buckie commented 9 years ago

Thanks again for the fast reply, let me know if there's anything else I should clean up. Apologies for not cleaning it up ahead of time. You may be right about unsafe being fine. @cartazio is right person to take up the topic with as I did the change at his behest and he knows GHC's runtime way better than I so I follow his lead on matters that concern it.

ghost commented 9 years ago

I reached out to Carter and got some good info. Unsafe is appropriate for very short lived calls (e.g. heap access in the single-digit us range), while nanomsg is reaching out to the network stack which could lock the world a lot longer, impacting for instance garbage collection.

Regardless, I'm sure favoring concurrency is the right choice for nanomsg users. If whatever tiny overhead a safe call involves posed an issue, you would be using a different architecture altogether.

Thanks for the patch. I just want to clean up some (unrelated) haddock formatting issues before pushing a new release to Hackage, could be a couple of days until I find the time.