[plt-scheme] Using Scheme_Object * from another thread

I'll go for the safe way, which means for SQLD SQLite, that
I'll have to allocate C pointers in the SQLite thread, executing the 
(synchronous)
SQL query; after the query has terminated, I'll need to copy the allocated
strings over to the mzscheme GC memory and free the C strings, which
is about the same as happens with PQExec now, because PostgreSQL's libpq
allocates strings itself.

Thanks anyway!

Hans




Matthew Flatt schreef:

>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>  
>
>>Hans Oesterholt-Dijkema wrote:
>>    
>>
>>>I thought Hans Boehms GC was thread safe. Are you sure?
>>>      
>>>
>
>I think we set the compilation flags so that the GC doesn't support
>threads. You could change that when compiling your own binary, of
>course.
>
>  
>
>>Suppose, I would like to build up an array of arrays of Scheme_Object *
>>in an other OS thread then the mzscheme main OS thread, using 
>>scheme_malloc(), etc.
>>and scheme_make_utf8_string(), while the calling thread in mzscheme is
>>waiting on mzscheme_block_until().
>>
>>Will this cause problems with mzscheme? (e.g. because schheme_malloc()/
>>scheme_make_utf8_string() is not OS thread safe).
>>    
>>
>
>When allocating a string through MzScheme, there's a little bit shared
>state other than the GC-private state. Specifically, there's a global
>function pointer that is used to escape when the GC runs out of memory
>trying to allocate the string. (This is one of the few places where
>MzScheme attempts to catch an out-of-memory condition and raise an
>exception.) See scheme_malloc_fail_ok() in "salloc.c".
>
>This race condition is unlikely to cause a problem in practice, because
>you won't allocate large strings. But I may have overlooked some other
>shared state (I didn't expect the one I found), so I recommend against
>using any scheme_...() functions from the non-MzScheme thread, even if
>you ensure that the GC itself is thread-safe.
>
>Matthew
>
>  
>