[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pika-dev] so... string work
From: |
Tom Lord |
Subject: |
Re: [Pika-dev] so... string work |
Date: |
Sat, 24 Jan 2004 15:27:59 -0800 (PST) |
> From: Matthew Dempsky <address@hidden>
> Tom Lord <address@hidden> writes:
> > So, to sum up the implications for Pika of that long thing:
> > Strings will be "vtable objects" containing a pointer to a `t_udstr'
> > (see src/hackerlab/strigns).
> I meant to ask this earlier, but when you say the vtable object should
> contain "a pointer to a t_udstr", is that intentional or
> accidental?
Accidental.
> Since t_udstr itself is a pointer value and I don't see any hackerlab
> routines yet that require a t_udstr *, am I missing something?
> A routine like:
> t_udstr scm_string_value (t_scm_arena arena, t_scm_word * value);
> should have a GC-independant lifetime like the scm_big(num|rat)_value
> functions.
That's a trickier issue.
It would be good to have
t_scm_error scm_extract_string (t_udstr * answer, [....])
but not an `scm_string_value' that gives you the _same_ t_udstr used
by the Scheme string (except in the innards).
The issue is t_udstr is not intended to be a thread-safe or async-safe
function. A t_udstr owned by a Scheme object may change size or
encoding or (data) address at essentially any time.
With one exception: This is what scm_lock_string_data and
scm_lock_string_data2 are for. Between them and the corresponding
scm_release_* call, the t_udstr(s) is (are) promised to be stable.
-t
- [Pika-dev] so... string work, Tom Lord, 2004/01/22
- [Pika-dev] Re: so... string work, Jose A. Ortega Ruiz, 2004/01/23
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/24
- Re: [Pika-dev] so... string work,
Tom Lord <=
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/24
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/24
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/24
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/24
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/24
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/25
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/25
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/25
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/25