I honestly don't think any of them are. They all have the potential to cause seriously *nasty* deadlocks.<div><br></div><div>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.</div>
<div><br></div><div>Besides, I don't think any of the synchronization primitives are shared/immutable-friendly (and probably can't be easily).</div><div><br></div><div>Regards,</div><div>Alex<br><br><div class="gmail_quote">
On Tue, May 1, 2012 at 7:26 PM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:andrei@erdani.com" target="_blank">andrei@erdani.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
TDPL doesn't prescribe one way or the other. What are some primitives in core that are reasonably useful to client high-level code?<br>
<br>
Andrei<div class="im"><br>
<br>
On 5/1/12 1:20 PM, Alex Rønne Petersen wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
My argument against this is just that these synchronization primitives<br>
more or less go completely against the paradigm that std.concurrency<br>
encourages. It just seems very awkward.<br>
<br>
Andrei, do you have any input on this?<br>
<br>
Regards,<br>
Alex<br>
<br>
On Tue, May 1, 2012 at 6:42 PM, Sean Kelly <<a href="mailto:sean@invisibleduck.org" target="_blank">sean@invisibleduck.org</a><br></div><div class="im">
<mailto:<a href="mailto:sean@invisibleduck.org" target="_blank">sean@invisibleduck.org</a><u></u>>> wrote:<br>
<br>
I think it was the suggestion that std.concurrency was to be the<br>
only import necessary for all things related to concurrency.<br>
core.thread was left out because spawn() was supposed to be used<br>
instead. I'd be fine with making the imports private though.<br>
<br>
On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:<br>
<br>
> I just looked over the concurrency chapter and couldn't find any<br>
mention of this.<br>
><br>
> Regards,<br>
> Alex<br>
><br>
> On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly<br></div><div class="im">
<<a href="mailto:sean@invisibleduck.org" target="_blank">sean@invisibleduck.org</a> <mailto:<a href="mailto:sean@invisibleduck.org" target="_blank">sean@invisibleduck.org</a><u></u>>> wrote:<br>
> On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > I just noticed that std.concurrency public imports more or less<br>
all of<br>
> > the synchronization modules from druntime. This caused a whole<br>
bunch<br>
> > of name conflicts in my code. Is this really needed? The<br>
average code<br>
> > written with std.concurrency is not going to need *any* of these<br>
> > primitives - I mean, that's the entire idea. In my case, I'm doing<br>
> > very low-level hackery/abuse inside a garbage collector<br>
> > implementation, so that doesn't really count as normal usage.<br>
> ><br>
> > I know it would be a breaking change, but could we please get<br>
rid of<br>
> > those public imports? I honestly doubt anyone's relying on<br>
these, and<br>
> > they're frankly a pain in the ass.<br>
> ><br>
> > (Also, the core.thread import is private, but these are public<br>
- wat?)<br>
><br>
><br>
> I think it's like this because TDPL stated it works this way.<br>
I'd have to re-read the chapter to be sure though.<br>
> ______________________________<u></u>_________________<br>
> phobos mailing list<br></div>
> <a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a> <mailto:<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a>><div class="im"><br>
> <a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/phobos</a><br>
><br>
> ______________________________<u></u>_________________<br>
> phobos mailing list<br></div>
> <a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a> <mailto:<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a>><div class="im"><br>
> <a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/phobos</a><br>
<br>
______________________________<u></u>_________________<br>
phobos mailing list<br></div>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a> <mailto:<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a>><div class="im"><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/phobos</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/phobos</a><br>
</div></blockquote>
</blockquote></div><br></div>