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 <[email protected] <mailto:[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]> <mailto:[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]> <mailto:[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]> <mailto:[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]> <mailto:[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]> <mailto:[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
