On 7/10/14, 7:24 AM, John Colvin wrote:
> On Thursday, 10 July 2014 at 14:14:20 UTC, Dicebot wrote:
>> On Thursday, 10 July 2014 at 14:09:41 UTC, John Colvin wrote:
>>> To be fair to Walter/Andrei, you need to be clear who your lieutenant
>>> is before you can delegate to them.
>>>
>>> Who has stepped up to take charge of concurrency in D?
>>
>> I think it should be other way around - announcing slot with listed
>> responsibilities / decision power and asking for volunteers, same as
>> it was done with release process "tzar" (kudos Andrew).
>>
>> Just "stepping up" is a no-op action without explicit delegation. Also
>> I believe every such domain needs two persons in charge and not just
>> one - for example, Sean Kelly is most suitable candidate for such role
>> but who accept his PR then? :)
>
> @ Walter & Andrei
> Would a list of subject areas that require delegation be a good idea to
> put on the wiki? A list of positions, both available and filled?

I think that's a good idea, I'll think of it.

In the meantime there seems to be a want of even foot soldiers and corporals, which seems to be a good way to promote lieutenants. In the post I just sent I pointed out a number of good and absolutely trivial pull requests for https://github.com/D-Programming-Language/phobos that simply sit there for days and weeks.


Andrei

On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu wrote:
> Then there's stuff I have no expertise in such as https://github.com/D-Programming-Language/phobos/pull/2307. Not only I'm not on hook for that, I better not discuss and pull that and leave it to someone who knows curl better.

I agree with most of what you have said (and definitely can be blamed guilty) but this situation was exactly what I had in mind for original rant. You don't feel that you are competent enough to judge that PR and everyone else (including those few who possibly can be proficient) does not feel authoritative enough make the decision. It is not your personal failure (and I apologize if my words sound like that) but general organizational problem.

I believe calling for explicit domains of responsibility ( as opposed to just giving push access :'( ) is one way to address that. Quite likely there are better approaches but those are for someone else to propose.

On Wednesday, 9 July 2014 at 21:47:47 UTC, Andrei Alexandrescu wrote:
> On 7/9/14, 1:51 PM, Walter Bright wrote:
>> On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
>>> Hmmm... how about using u after that?
>>
>> Using u after that would either cause an exception to be thrown, or
>> they'd get T.init as a value. I tend to favor the latter, but of course
>> those decisions would have to be made as part of the design of Unique.
>
> That semantics would reenact the auto_ptr disaster so probably wouldn't be a good choice. -- Andrei

The problem with auto_ptr is that people rarely used it for what it was designed for.  Probably because it was the only smart pointer in the STL.  As I'm sure you're aware, the purpose of auto_ptr is to explicitly define ownership transfer of heap data.  For that it's pretty much perfect, and I use it extensively.  It looks like unique_ptr is pretty much the same, but with a facelift.  Underneath it still performs destructive copies, unless I've misread the docs.

> E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some
apparently work that's just sitting there abandoned.

Hm, slightly OT: is it considered widely acceptable to take over such pull requests by reopening rebased one with identical content? I presume Boost licensing implies so but not sure everyone else expects the same.

On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
> On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu wrote:
>> We already have actor-style via std.concurrency. We also have fork-join parallelism via std.parallel. What we need is a library for CSP.
>
> The actor-style via std.concurrency is only between 'heavyweight' threads though, no? Even if lightweight threads may be overhyped, part of the appeal of Go and Erlang is that one can spawn tens of thousands of threads and it 'just works'. It allows the server model of 'one green thread/actor per client', which has a certain appeal in its simplicity. Akka similarly uses its own lightweight threads, not heavyweight JVM threads.

No.  I've had an outstanding pull request to fix this for quite a while now.  I think there's a decent chance it will be in the next release.  To be fair, that pull request mostly provides the infrastructure for changing how concurrency is handled.  A fiber-based scheduler backed by a thread pool doesn't exist yet, though it shouldn't be hard to write (the big missing piece is having a dynamic thread pool).  I was going to try and knock one out while on the airplane in a few days.


> Message passing between lightweight threads can also be much faster than message passing between heavyweight threads; take a look at the following message-passing benchmark and compare Haskell, Go and Erlang to the languages using OS threads: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring

Thanks for the benchmark.  I didn't have a good reference for what kind of performance capabilities to hit, so there are a few possible optimizations I've left out of std.concurrency because they didn't buy much in my own testing (like a free list of message objects).  I may have to revisit those ideas with this benchmark in mind and see what happens.

On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
>
> Reading the code in the pull request [1], for instance, makes me wonder how to tell if `spawn()` is spawning a thread or a fibre. Can a tid refer to a fibre? If so, why's it called a thread ID, and how do I tell if a particular tid refers to a thread or fibre? It would be great to have these kinds of questions answered in an easily available reference (for instance, the documentation for std.concurrency, which currently doesn't even mention fibres or vibe.d).

That was a deliberate design decision--you're not supposed to know, or care, what it's spawning.  This also allows up to change the scheduling algorithm without affecting user code.  That said, because statics are thread-local by default, and because implementing fiber-local storage in a C-compatible language would be difficult, the scheduler is user-configurable.  So there is some visibility into this, just not as a part of the normal spawn/send/receive flow.

On Thursday, 10 July 2014 at 11:19:26 UTC, Dicebot wrote:
>
> Problem is that this is most simple PR to simply add message-passing support for fibers. Adding some advanced schedulers with worker thread pool can be expected to be done on top but.. This small PR has been rotting there for ages with pretty much zero attention but from few interested persons.

Yep.  It's been gathering dust but for the occasional request to rebase the code.  A better scheduler can be added, but I think that should follow this pull request's addition to Phobos.  I don't want to block the infrastructure from acceptance because people have issues with a complicated scheduler that happened to be bundled with it.  Though as it is, one of the pull requests I created for Druntime for a Facebook request has sat for months, presumably because of a request regarding a documentation formatting change that I overlooked.  And I know I'm not alone.  Robert's struggle with getting std.logger accepted is the stuff told to children around the campfire so they don't venture out into the dark.

On Thursday, 10 July 2014 at 14:54:51 UTC, Dicebot wrote:
>> E.g.
> https://github.com/D-Programming-Language/phobos/pull/1527 is some
> apparently work that's just sitting there abandoned.
>
> Hm, slightly OT: is it considered widely acceptable to take over such pull requests by reopening rebased one with identical content? I presume Boost licensing implies so but not sure everyone else expects the same.

I don't see why this would invalidate the licence:

fork the branch that contains the request, rebase to fix any conflicts, make any extra commits needed, open a new pull request. It's really no different from merging the pull and then fixing it afterwards.

On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu wrote:
>
> Switching to newer pull requests, there are simple and obviously good pull requests that just sit there for anyone to pull.

This.  I think pull requests tend to sit because people don't feel they have the authority to push the button, and all the author can do is ask.  I know I should be a better shepherd of Druntime as well, and should have some actual free time in about another month where I hope to start catching up.

On 7/10/14, 7:54 AM, Dicebot wrote:
>> E.g.
> https://github.com/D-Programming-Language/phobos/pull/1527 is some
> apparently work that's just sitting there abandoned.
>
> Hm, slightly OT: is it considered widely acceptable to take over such
> pull requests by reopening rebased one with identical content? I presume
> Boost licensing implies so but not sure everyone else expects the same.

That's totally on topic! I think it's fair game to take over pull requests of which authors did not respond to repeated pings. -- Andrei