www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I would like to draw attention regarding std.signals

reply 12345swordy <alexanderheistermann gmail.com> writes:
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
Sep 04
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
Sep 05
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
Sep 05
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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
Sep 05
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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
Sep 05
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
Sep 05
parent 12345swordy <alexanderheistermann gmail.com> writes:
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
Sep 05
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Sep 05
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 5 September 2017 at 22:04:15 UTC, Jonathan M Davis 
wrote:
 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 say signals are not for multithreading, especially if they are for GUI.
Sep 06
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 6 September 2017 at 09:50:22 UTC, Kagamin wrote:
 On Tuesday, 5 September 2017 at 22:04:15 UTC, Jonathan M Davis 
 wrote:
 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 say signals are not for multithreading, especially if they are for GUI.
Why do you think that boost library signals2 exist then?
Sep 07
prev sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
Sep 05
prev sibling parent Kagamin <spam here.lot> writes:
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.
Sep 06