[racket] Continuation in embedding Racket

Whats Your opinion is it possible to localize memory which responsible for continuations in heap? May be I could try to make a patch or dirty hack(for example swicth stack pointer for every racket API call :))

05.12.2014, 15:27, "Matthew Flatt" <mflatt at cs.utah.edu>:
> At Thu, 04 Dec 2014 00:23:37 +0300, Nesterov Kirill wrote:
>>>   (call-with-continuation-prompt (lambda () (generate-digit)))
>>  With this I'm getting segfault.
>
> Sorry for the delay! Looking back at your original explanation:
>>>  At Wed, 03 Dec 2014 23:45:28 +0300, Nesterov Kirill wrote:
>>>>   I'm trying to embed racket 3m version as interpreter into GUI
>>>>  application. For  custom interpreters this application have two
>>>>  required APIs - first one is init  and the second one is eval
>>>>  string. So in init I'm calling  scheme_register_tls_space and
>>>>  scheme_main_setup after. And in eval I'm using  custom version of
>>>>  Racket's read-eval-print-loop without recursion for  evaluation of
>>>>  thrings.
>
> I think you're saying that Racket_cli_execute_line() is not called
> within the function passed to scheme_main_setup(), but is instead
> called after scheme_main_setup() returns.
>
> If so, that would explain the crash when trying to use continuations.
> The Racket run-time system expects to be within the call to
> scheme_main_setup() always, so that it can manipulate the C stack to
> implement continuations, threads, etc.
>
> Having to put all calls to Racket inside scheme_main_setup() can be
> awkward for an embedding application. When the embedding application
> can't be organized so that all calls are within scheme_main_setup(), a
> possible approach is to put Racket into its own OS-level thread. The
> scheme_main_setup() function would be called in that thread, and the
> function passed to scheme_main_setup() would wait for evaluation
> requests from other threads. Then, Racket_cli_execute_line() would send
> a request to that thread and wait for the response.
>
> Of course, putting Racket into its own OS thread can complicate
> interactions between Racket and the embedding application, especially
> if Racket calls back to the embedding environment. Unfortunately, we
> don't have a better answer at the moment.