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 <[email protected]>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 <[email protected] >> <mailto:[email protected]**>> 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 >> <[email protected] <mailto:[email protected]**>> 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 >> > [email protected] <mailto:[email protected]> >> >> > >> http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos> >> > >> > ______________________________**_________________ >> > phobos mailing list >> > [email protected] <mailto:[email protected]> >> >> > >> http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos> >> >> ______________________________**_________________ >> phobos mailing list >> [email protected] <mailto:[email protected]> >> >> >> http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos> >> >> >> >> >> ______________________________**_________________ >> phobos mailing list >> [email protected] >> http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos> >> >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
