The current bug that I like to focus on is the following:
"Not safe for multiple threads operating on the same signals or slots. "

However boost.signals2 is thread safe, so I was wondering what is currently preventing std.signals from being thread safe? How hard is it currently?


Alex

On Monday, 4 September 2017 at 23:19:31 UTC, 12345swordy wrote:
> The current bug that I like to focus on is the following:
> "Not safe for multiple threads operating on the same signals or slots. "
>
> However boost.signals2 is thread safe, so I was wondering what is currently preventing std.signals from being thread safe? How hard is it currently?

I don't really know, but there are some alternatives on dub that try to improve on std.signals, for example https://code.dlang.org/packages/phobosx. Not sure thread safety is part of the efforts.

Bastiaan.

On Tuesday, 5 September 2017 at 12:09:55 UTC, Bastiaan Veelo wrote:
> On Monday, 4 September 2017 at 23:19:31 UTC, 12345swordy wrote:
>> The current bug that I like to focus on is the following:
>> "Not safe for multiple threads operating on the same signals or slots. "
>>
>> However boost.signals2 is thread safe, so I was wondering what is currently preventing std.signals from being thread safe? How hard is it currently?
>
> I don't really know, but there are some alternatives on dub that try to improve on std.signals, for example https://code.dlang.org/packages/phobosx. Not sure thread safety is part of the efforts.
>
> Bastiaan.

The recent updated is from 2015. That's not what I consider to be ideal.

Regardless if the bug were to be simply fixed by using mutex then it would have it done so already. This implies that it's more difficult then it seems which is why I am asking how hard currently.

On Tuesday, 5 September 2017 at 13:27:44 UTC, 12345swordy wrote:
> On Tuesday, 5 September 2017 at 12:09:55 UTC, Bastiaan Veelo wrote:
>> I don't really know, but there are some alternatives on dub that try to improve on std.signals, for example https://code.dlang.org/packages/phobosx. Not sure thread safety is part of the efforts.
>>
>> Bastiaan.
>
> The recent updated is from 2015. That's not what I consider to be ideal.

I assume you think that is a long time. It could also mean it is stable.

All I am saying is before you start looking into fixing the existing std.signals, it may be beneficial to look at improvements that others have made. The review thread is here [1], voting thread is here [2] (it was a tie). It was not accepted into phobos due to lack of thorough review and too little interest. Some people think std.signals should be deprecated and removed altogether, others think it is a shame it didn't get in. Positive feedback exists [3, 4].

Maybe you are the right person to brush this implementation up, address the critiques, and open a new PR. According to [5] it is already thread safe.

Bastiaan.

[1] http://forum.dlang.org/post/ujlhznaphepibgtpcoqz@forum.dlang.org
[2] http://forum.dlang.org/post/nhnitsaqijyhnmgcumux@forum.dlang.org
[3] http://forum.dlang.org/post/mkm17h$1ic$50@digitalmars.com
[4] https://issues.dlang.org/show_bug.cgi?id=17011
[5] http://forum.dlang.org/post/sxuiargigylszcurpdnr@forum.dlang.org

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.

Alex

On Tuesday, 5 September 2017 at 15:05:09 UTC, 12345swordy wrote:
> I am not interested in add features like the other guy did, I am interested in fixing the bug regarding thread safety.

Sure, ripping out the extra features and keeping the fixes might be what would get this accepted. I didn't review it though, so I'm not sure. Anyway, it's your call.

Bastiaan.

On Tuesday, 5 September 2017 at 15:18:08 UTC, Bastiaan Veelo wrote:
> On Tuesday, 5 September 2017 at 15:05:09 UTC, 12345swordy wrote:
>> I am not interested in add features like the other guy did, I am interested in fixing the bug regarding thread safety.
>
> Sure, ripping out the extra features and keeping the fixes might be what would get this accepted. I didn't review it though, so I'm not sure. Anyway, it's your call.
>
> Bastiaan.

I am not planning to use the library that you have link earlier.

Alex

On Tuesday, 5 September 2017 at 14:55:20 UTC, Bastiaan Veelo wrote:
> According to [5] it  is already thread safe.
>
> [5] http://forum.dlang.org/post/sxuiargigylszcurpdnr@forum.dlang.org

The docs seem to state the contrary, though:
> * This struct is not thread-safe in general, it just handles the
> * concurrent parts of the GC.

https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d

Bastiaan.

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

On Tuesday, 5 September 2017 at 13:27:44 UTC, 12345swordy wrote:
> ideal
Nothing like that can ever exist. There's another guy trying to do this: https://forum.dlang.org/post/okpsweshfmbohjvfdvsw@forum.dlang.org maybe you can borrow his code.