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