I would like to draw attention regarding std.signals

[Jonathan M Davis via Digitalmars-d]

On Tuesday, September 05, 2017 15:05:09 12345swordy via Digitalmars-d wrote:
> On Tuesday, 5 September 2017 at 14:55:20 UTC, Bastiaan Veelo
>
> wrote:
> > On Tuesday, 5 September 2017 at 13:27:44 UTC, 12345swordy wrote:
> >> [...]
> >
> > I assume you think that is a long time. It could also mean it
> > is stable.
> >
> > [...]
>
> There is lack of interest regarding event driven programming!?
> I am not interested in add features like the other guy did, I am
> interested in fixing the bug regarding thread safety.

Certainly, anyone doing it is either using something else completely or is
just using std.signals as it is, and there seems to be almost zero interest
in doing anything with std.signals. Occasionally, someone pops up who cares
and says something about it, but largely std.signals is just left as-is and
at least does not appear to be a module that many folks care about. So,
either it works well enough for folks, or there really isn't much interest.
Looking at git blame, it does look like some work has been done on it in the
last couple of years, but I think that most of it was for documentation.
std.signals is an older module, and I don't think that anyone in particular
is really maintaining it. So, it really only gets work done on it when
someone decides that something needs fixing and steps in to do it. There has
occasionally been talk of redoing it from someone who care about it, but the
interest from others in the newsgroup has generally been pretty low.

Personally, the only times that I've done anything that involved something
like this have been for GUI programming, and that usually involves
mechanisms connected to the GUI toolkit. If I were looking to do anything
that involved sending messages across threads, I'd be using std.concurrency,
not std.signals, and if I weren't specifically dealing with multiple
threads, I wouldn't see much point in the whole signals and slots thing. I'd
just call the function. That's not to say that someone else wouldn't find
what std.signals is doing valuable, but I personally don't see much point.

Regardless, if you see an issue with std.signals or any other module in
Phobos that you think should be fixed, feel free to fix it and create a pull
request. If it's a massive overhaul, that would involve having to go through
the whole Phobos review process that goes with adding or replacing a module,
but for smaller stuff, you can just create a PR up on github. Largely, stuff
gets done around here because someone who cares steps up and does it, and
everyone has different things they care about, and not everyone has time to
work on stuff, and those that do, rarely have as much time as they'd like.
So, the work that gets done doesn't always match up with what someone in
particular is looking for, and often, the best way to fix that is to just do
it yourself. Ultimately, _someone_ has to, or it won't get done, and most
things that get done around here get done, because someone is scratching
their own itch, so to speak.

- Jonathan M Davis