I have a question about the C interface. It appears necessary to decrement the reference count of ___STILL objects before returning them:
___SCMOBJ foo() { ___SCMOBJ result; ___EXT(___CHARSTRING_to_SCMOBJ) ("hello", &result, 0); ___release_scmobj (result); return result; }
Why is there not a race condition between decrementing the reference count (___release_scmobj) and returning the result? What if another thread wakes up the GC in the meantime?
Afficher les réponses par date
Michael South wrote:
I have a question about the C interface. It appears necessary to decrement the reference count of ___STILL objects before returning them:
___SCMOBJ foo() { ___SCMOBJ result; ___EXT(___CHARSTRING_to_SCMOBJ) ("hello", &result, 0); ___release_scmobj (result); return result; }
Why is there not a race condition between decrementing the reference count (___release_scmobj) and returning the result? What if another thread wakes up the GC in the meantime?
It's safe because Gambit does not (yet!?) support OS threads and a Gambit thread switch cannot occur at this point in your code.
Guillaume
On 19-Sep-07, at 7:41 AM, Michael South wrote:
I have a question about the C interface. It appears necessary to decrement the reference count of ___STILL objects before returning them:
Yes.
___SCMOBJ foo() { ___SCMOBJ result; ___EXT(___CHARSTRING_to_SCMOBJ) ("hello", &result, 0); ___release_scmobj (result); return result; }
Note that it would be much less hassle to write:
(c-declare #<<EOS char *foo() { return "hello"; } EOS )
(define foo (c-lambda () char-string "foo"))
Why is there not a race condition between decrementing the reference count (___release_scmobj) and returning the result? What if another thread wakes up the GC in the meantime?
Threading is implemented in Scheme (using continuations). Operating system threads are not currently implemented. The context switching is thus only possible outside of C functions like foo. Consequently there is no race condition.
Marc