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
