[phobos] Why does std.concurrency public import a bunch of synchronization primitive modules from druntime?
Alex Rønne Petersen
xtzgzorex at gmail.com
Tue May 1 13:54:43 PDT 2012
How are we going to do this? It's not obvious in the documentation that
std.concurrency imports these core modules at all anyway. Do we want a
proper deprecation process or just private-ify the imports here and now?
Regards,
Alex
On Tue, May 1, 2012 at 8:21 PM, Andrei Alexandrescu <andrei at erdani.com>wrote:
> 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>
>> <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>
>> <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>
>> <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>
>> <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/e808a1b3/attachment.html>
More information about the phobos
mailing list