www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - nogc required on C API callbacks?

reply "Brian Schott" <briancschott gmail.com> writes:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/signal.d

When  nogc was added to the top of that file, the type of sigfn_t 
changed from "void function(int) extern (C)  system nothrow" to 
"void function(int) extern (C)  system nothrow  nogc".

This breaks some code such as the ae library used by Digger. (The 
 nogc annotation is now required on signal handlers). The 
argument for requiring  nogc on C library callbacks makes sense 
to me, so I'd like to know if this was intentional.
Jul 09 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 12:54 PM, Brian Schott wrote:
 https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/signal.d


 When  nogc was added to the top of that file, the type of sigfn_t changed from
 "void function(int) extern (C)  system nothrow" to "void function(int) extern
 (C)  system nothrow  nogc".

 This breaks some code such as the ae library used by Digger. (The  nogc
 annotation is now required on signal handlers). The argument for requiring
 nogc
 on C library callbacks makes sense to me, so I'd like to know if this was
 intentional.
I agree that callbacks shouldn't throw. The problem is existing code uses callbacks that aren't annotated with 'nothrow', and we don't like breaking all their code.
Jul 09 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 9 July 2014 at 19:59:21 UTC, Walter Bright wrote:
 I agree that callbacks shouldn't throw. The problem is existing 
 code uses callbacks that aren't annotated with 'nothrow', and 
 we don't like breaking all their code.
I was talking about nogc (added in April, so before the 2.066 beta and after the 2.065 release). nothrow has been there since 2012 according to git blame, so nothrow is not what's causing the signal handling code to not compile.
Jul 09 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 1:08 PM, Brian Schott wrote:
 On Wednesday, 9 July 2014 at 19:59:21 UTC, Walter Bright wrote:
 I agree that callbacks shouldn't throw. The problem is existing code uses
 callbacks that aren't annotated with 'nothrow', and we don't like breaking all
 their code.
I was talking about nogc (added in April, so before the 2.066 beta and after the 2.065 release). nothrow has been there since 2012 according to git blame, so nothrow is not what's causing the signal handling code to not compile.
Yes, you're right, I realized that after I posted it.
Jul 09 2014
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 9 July 2014 at 19:54:11 UTC, Brian Schott wrote:
 https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/signal.d

 When  nogc was added to the top of that file, the type of 
 sigfn_t changed from "void function(int) extern (C)  system 
 nothrow" to "void function(int) extern (C)  system nothrow 
  nogc".

 This breaks some code such as the ae library used by Digger. 
 (The  nogc annotation is now required on signal handlers). The 
 argument for requiring  nogc on C library callbacks makes sense 
 to me, so I'd like to know if this was intentional.
After doing a bit more searching on the bug tracker I discovered that this is another instance of https://issues.dlang.org/show_bug.cgi?id=12710 https://issues.dlang.org/show_bug.cgi?id=12738 I'll create a pull request that rearranges a few more of these attributes.
Jul 09 2014
parent "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 9 July 2014 at 22:20:16 UTC, Brian Schott wrote:
 I'll create a pull request that rearranges a few more of these 
 attributes.
https://github.com/D-Programming-Language/druntime/pull/879 Can I get somebody to look at this?
Jul 10 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 09/07/14 21:54, Brian Schott wrote:

 The argument for
 requiring  nogc on C library callbacks makes sense to me, so I'd like to
 know if this was intentional.
Why shouldn't you be able to allocate GC memory from C? -- /Jacob Carlborg
Jul 09 2014
parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Thursday, 10 July 2014 at 06:47:37 UTC, Jacob Carlborg wrote:
 Why shouldn't you be able to allocate GC memory from C?
This isn't a plain old C function, it's an asynchronous signal handler.
Jul 10 2014
parent Jacob Carlborg <doob me.com> writes:
On 10/07/14 21:21, safety0ff wrote:

 This isn't a plain old C function, it's an asynchronous signal handler.
I though the signal handler was just an example and this was a more general question. -- /Jacob Carlborg
Jul 10 2014