[phobos] Why does std.concurrency public import a bunch of synchronization primitive modules from druntime?

[Andrei Alexandrescu]

Then we probably should deprecate the import.

Andrei

On 5/1/12 1:58 PM, Alex Rønne Petersen wrote:
> I honestly don't think any of them are. They all have the potential to
> cause seriously *nasty* deadlocks.
>
> I could maybe see myself using core.sync.barrier in some very specific
> cases, but that's only because I've dealt with message-passing systems a
> lot and know how to avoid the most common pitfalls when doing
> synchronization in them. IMHO we should be directing people away from
> synchronization primitives when doing message-passing and maybe even
> make it clearer in the documentation that using them in message-passing
> systems is a recipe for disaster, may eat your laundry, etc.
>
> Besides, I don't think any of the synchronization primitives are
> shared/immutable-friendly (and probably can't be easily).
>
> Regards,
> Alex
>
> On Tue, May 1, 2012 at 7:26 PM, Andrei Alexandrescu <andrei at erdani.com
> <mailto:andrei at erdani.com>> wrote:
>
>     TDPL doesn't prescribe one way or the other. What are some
>     primitives in core that are reasonably useful to client high-level code?
>
>     Andrei
>
>
>     On 5/1/12 1:20 PM, Alex Rønne Petersen wrote:
>
>         My argument against this is just that these synchronization
>         primitives
>         more or less go completely against the paradigm that std.concurrency
>         encourages. It just seems very awkward.
>
>         Andrei, do you have any input on this?
>
>         Regards,
>         Alex
>
>         On Tue, May 1, 2012 at 6:42 PM, Sean Kelly
>         <sean at invisibleduck.org <mailto:sean at invisibleduck.org>
>         <mailto:sean at invisibleduck.org
>         <mailto:sean at invisibleduck.org>__>> wrote:
>
>             I think it was the suggestion that std.concurrency was to be the
>             only import necessary for all things related to concurrency.
>               core.thread was left out because spawn() was supposed to
>         be used
>             instead.  I'd be fine with making the imports private though.
>
>             On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:
>
>          > I just looked over the concurrency chapter and couldn't find any
>             mention of this.
>          >
>          > Regards,
>          > Alex
>          >
>          > On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly
>         <sean at invisibleduck.org <mailto:sean at invisibleduck.org>
>         <mailto:sean at invisibleduck.org
>         <mailto:sean at invisibleduck.org>__>> wrote:
>          > On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
>          >
>          > > Hi,
>          > >
>          > > I just noticed that std.concurrency public imports more or less
>             all of
>          > > the synchronization modules from druntime. This caused a whole
>             bunch
>          > > of name conflicts in my code. Is this really needed? The
>             average code
>          > > written with std.concurrency is not going to need *any* of
>         these
>          > > primitives - I mean, that's the entire idea. In my case,
>         I'm doing
>          > > very low-level hackery/abuse inside a garbage collector
>          > > implementation, so that doesn't really count as normal usage.
>          > >
>          > > I know it would be a breaking change, but could we please get
>             rid of
>          > > those public imports? I honestly doubt anyone's relying on
>             these, and
>          > > they're frankly a pain in the ass.
>          > >
>          > > (Also, the core.thread import is private, but these are public
>             - wat?)
>          >
>          >
>          > I think it's like this because TDPL stated it works this way.
>               I'd have to re-read the chapter to be sure though.
>          > _________________________________________________
>          > phobos mailing list
>          > phobos at puremagic.com <mailto:phobos at puremagic.com>
>         <mailto:phobos at puremagic.com <mailto:phobos at puremagic.com>>
>
>          > http://lists.puremagic.com/__mailman/listinfo/phobos
>         <http://lists.puremagic.com/mailman/listinfo/phobos>
>          >
>          > _________________________________________________
>          > phobos mailing list
>          > phobos at puremagic.com <mailto:phobos at puremagic.com>
>         <mailto:phobos at puremagic.com <mailto:phobos at puremagic.com>>
>
>          > http://lists.puremagic.com/__mailman/listinfo/phobos
>         <http://lists.puremagic.com/mailman/listinfo/phobos>
>
>             _________________________________________________
>             phobos mailing list
>         phobos at puremagic.com <mailto:phobos at puremagic.com>
>         <mailto:phobos at puremagic.com <mailto:phobos at puremagic.com>>
>
>         http://lists.puremagic.com/__mailman/listinfo/phobos
>         <http://lists.puremagic.com/mailman/listinfo/phobos>
>
>
>
>
>         _________________________________________________
>         phobos mailing list
>         phobos at puremagic.com <mailto:phobos at puremagic.com>
>         http://lists.puremagic.com/__mailman/listinfo/phobos
>         <http://lists.puremagic.com/mailman/listinfo/phobos>
>
>