[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pika-dev] so... string work
From: |
Matthew Dempsky |
Subject: |
Re: [Pika-dev] so... string work |
Date: |
Sat, 24 Jan 2004 22:26:58 +0100 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Tom Lord <address@hidden> 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
- [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, 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 <=
- 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