Re: so... string work

Tom Lord <lord-1tv/[email protected]> writes:

> Not much more, no.
>
> In a threaded context, if locking is per-string (rather than say,
> locking of all strings -- or locking of all threads generally) then
> scm_lock_string_data2 needs to be concerned with deadlock.
>
> The alternative here is to have something like scm_lock_string_data
> and scm_lock_string_data_instantly_or_fail and scm_string_lock_order
> (a total ordering of string objects) -- and require client code to
> manage lock priorities sanely.  It seemed far simpler just to capture
> the two common cases of wanting to work on one string or two and hide
> the deadlock issues inside of reps/.

Hm, I guess I should move the core scaffolding I've written into
strings-reps.[ch] then... (I was thinking at first strings would
suffice as a purely libscm type, but I guess not.)

-jivera