Are libraries expected to enforce safe usage of thread-unsafe functions?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Are libraries expected to enforce safe usage of thread-unsafe functions?

Thomas Koster
Hi friends,

I am writing a library that has Handle-like values for resources that are not thread-safe (foreign state from a non-thread-safe C library). In other words, a resource can only be "used" by one Haskell thread at a time. Unless I take steps, if one shares the resource between concurrent Haskell threads, bad things will happen at runtime (even with a single-threaded runtime).

Naturally, I want consumers to use my library safely, so I am considering making it safe for all by pessimistically enforcing safe usage with MVars.

Is it common/expected that Haskell libraries enforce safe access like this?

MVars are not free from cost, but are they cheap (i.e. almost as fast as no forced synchronization) as long as no blocking/rescheduling occurs?

Thanks,
--
Thomas Koster


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Are libraries expected to enforce safe usage of thread-unsafe functions?

Benjamin Edwards
Presumably you will have a safe and an unsafe variant of each function, the safe one calling its corresponding unsafe variant guarded by an appropriate locking mechanism. Just export both and note why the unsafe variants are marked "unsafe". Separating policy from implementation is always nice for callers. Presumably they know their application and what they are willing to pay for each call.

Best,
Ben

On Tue, 12 Apr 2016 at 08:57 Thomas Koster <[hidden email]> wrote:
Hi friends,

I am writing a library that has Handle-like values for resources that are not thread-safe (foreign state from a non-thread-safe C library). In other words, a resource can only be "used" by one Haskell thread at a time. Unless I take steps, if one shares the resource between concurrent Haskell threads, bad things will happen at runtime (even with a single-threaded runtime).

Naturally, I want consumers to use my library safely, so I am considering making it safe for all by pessimistically enforcing safe usage with MVars.

Is it common/expected that Haskell libraries enforce safe access like this?

MVars are not free from cost, but are they cheap (i.e. almost as fast as no forced synchronization) as long as no blocking/rescheduling occurs?

Thanks,
--
Thomas Koster

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Are libraries expected to enforce safe usage of thread-unsafe functions?

Thomas Koster
Ben,

On 12 April 2016 at 17:57, Thomas Koster <[hidden email]> wrote:
> I am writing a library that has Handle-like values for resources that are
> not thread-safe (foreign state from a non-thread-safe C library).
>
> Naturally, I want consumers to use my library safely, so I am considering
> making it safe for all by pessimistically enforcing safe usage with MVars.
>
> Is it common/expected that Haskell libraries enforce safe access like this?

On 12 April 2016 at 18:48, Benjamin Edwards <[hidden email]> wrote:
> Presumably you will have a safe and an unsafe variant of each function, the
> safe one calling its corresponding unsafe variant guarded by an appropriate
> locking mechanism. Just export both and note why the unsafe variants are
> marked "unsafe". Separating policy from implementation is always nice for
> callers. Presumably they know their application and what they are willing to
> pay for each call.

Good idea. At this time I think I will do just that. Easy to benchmark
to measure the cost difference too.

Thanks,
Thomas Koster
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe