[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: food for thought re: string representations ["Boehm, Hans" <address@

From: Dirk Herrmann
Subject: Re: food for thought re: string representations ["Boehm, Hans" <address@hidden>] RE: Re: [gclist] ref-counting performance cost
Date: Fri, 13 Oct 2000 12:53:46 +0200 (MEST)

On Thu, 12 Oct 2000, Dirk Herrmann wrote:

> For scheme, the problem does not exist in this way, since there is no
> pointer to a character within a string.  All accesses to characters within
> a string go through the string object itself.

Well, as long as you work on the scheme level.  In fact, in the context of
copy-on-write strings with threads, the following does not work:

print_string (SCM string)
  scm_sizet length = SCM_STRING_LENGTH (string);
  char *chars = SCM_STRING_CHARS (string);
  scm_sizet i;

  for (i = 0; i < length; ++i)
    scm_putc (chars [i]);

The reason is, that while the string is being printed, a different thread
might modify the same string object, thus causing a copy-on-write.  Thus,
suddenly the `chars' pointer becomes invalid.  It may be that the old
memory region pointed to by `chars' remains accessible (as long as there
are other objects exist that share that region), but it may also be that
also all other references to the memory region get lost.  Then, if a
garbage collection happens in between, the `chars' pointer points into
freed memory.

This means, on the C level, while one is working on the characters of a
string, it has to be guaranteed that the memory-region does not get
garbage collected in between.

Thus, if guile would be changed to use a copy-on-write string
implementation, every use of SCM_STRING_CHARS would have to be revisited
with respect to thread safety, making sure that the corresponding pointer
remains valid throughout its use.

Best regards

reply via email to

[Prev in Thread] Current Thread [Next in Thread]