Re: proposal: scm_string2str() and scm_symbol2str()

[stefan]

On Mon, 3 Dec 2001, Dirk Herrmann wrote:

> On Fri, 30 Nov 2001, stefan wrote:
> 
> > On Thu, 29 Nov 2001, Dirk Herrmann wrote:
> > 
> > > > > > We could make life easier, if we supplied the following:
> > > > > > 
> > > > > > typedef void * (* scm_t_malloc_func) (size_t);
> > > > > > typedef void (* svz_t_free_func) (void *);
> > > > > > 
> > > > > > SCM_API scm_t_malloc_func scm_c_malloc = malloc;
> > > > > > SCM_API scm_t_free_func scm_c_free = free;
> > > > > 
> > > > > Doesn't _every_ library on Win32 has this problem?  Do they all solve
> > > > > it on their own?
> > > > 
> > > > Yes.  Portable programs solve this problem.  Especially the ancient
> > > > libraries like `zlib' all provide such functionality if necessary.  The
> > > > function pointers seems to be the favourite...
> > > 
> > > Unfortunately it doesn't work well with threads, at least not in the way
> > > you are suggesting.
> > 
> > I am not sure what you mean.  Threads are meant to share data?  You might
> > setup the 
> > 
> > {
> >   scm_c_malloc = malloc;
> > }
> > 
> > for each thread you are starting.  Is this what you mean? No, can't be,
> > its a part of data, too...  Have no clue.  Could you please explain?
> 
> If there is one global variable scm_c_malloc, then setting it within one
> thread may interfere with another thread that expects scm_c_malloc to be
> set differently.  In other words, you would have to introduce some locking
> mechanism to guarantee that the sequence of setting scm_c_malloc and
> calling scm_string2str can not be interrupted by a different thread that
> sets scm_c_malloc to a different value.

I see your point.  Are we going to implement it this way despite these
consideration being non-thread-safe?  If not:  Do we have thread-specific
data?  Any more proposals?  If yes: I could do it.

Cheers,
        address@hidden