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@erdani.com
<mailto:
andrei@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@invisibleduck.org <mailto:
sean@invisibleduck.org>
<mailto:
sean@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@invisibleduck.org <mailto:
sean@invisibleduck.org>
<mailto:
sean@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.
> http://lists.puremagic.com/__mailman/listinfo/phobos
<http://lists.puremagic.com/mailman/listinfo/phobos>
>
> _________________________________________________
<mailto:phobos@puremagic.com <mailto:phobos@puremagic.com>>
> http://lists.puremagic.com/__mailman/listinfo/phobos
<http://lists.puremagic.com/mailman/listinfo/phobos>
_________________________________________________
<mailto:phobos@puremagic.com <mailto:phobos@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>