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

[Alex Rønne Petersen]

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>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**>> 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**>> 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>
>>
>>     > 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>
>>
>>    ______________________________**_________________
>>    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>
>>
>>
>>
>>
>> ______________________________**_________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20120501/1ea71e81/attachment-0001.html>