>> In DivaScheme, I find myself hitting a race condition between DivaScheme
>> and DrScheme: I'm trying to avoid touching the interaction buffer while
>> evaluation is taking place. I was hoping to put something like:
>>>> (define (update-text text)
>> (wait-for-io-to-complete)
>> ... )
>>>> within my code. I've grepped for it, but I haven't found
>> wait-for-io-to-complete anywhere in the DrScheme code base.
>> Probably this isn't the way to do this -- the way to avoid race
> conditions is to do all of the modification of the drscheme editor on
> the thread of drscheme's eventspace.
Ah, ok; that means that I was (am? *grin*) confused and don't know what
I'm talking about yet.
I thought that repl interaction ran on a separate thread of execution from
the drscheme main thread, having glanced through the DrScheme source code.
I had assumed that when something is being executed, that the userspace
thread somehow locks the interaction text% from edits outside the
userspace thread, and that WAIT-FOR-IO-TO-COMPLETE was a way for the
DrScheme thread to wait for the userspace evaluation thread to release its
semaphore. I now think I was wrong about that.
I took a close look at my bug, and saw that it really to do with a
separate issue: my code had been trying to munge with repl prompt snips
("> "), which are read-only snippets (as they should be!). So that's why
my text% mixin code was reporting (CAN-INSERT? ...) as false.
I found a workaround for my problem, so finding WAIT-FOR-IO-TO-COMPLETE is
less urgent than it was before.