| 2011-03-02 06:43:23 |
Nikodemus Siivola |
description |
While our current policy is not unreasonable, it makes doing something elementary -- eliminating strictly unsafe hash-table accesses from a codebase far harder than it should be.
I propose the following:
1. Hash-tables should be synchronized by default, so that portable library code has a prayer of doing the right thing. Code that cannot pay the overhead of synchronization can still request unsychronized tables explicitly.
2. Synchronized hash-tables need to be safe to modify while iteration is happening in another thread.
WITH-LOCKED-HASH-TABLE is still needed to make interning into a hash-table work right
(with-locked-hash-table (table)
(or (gethash key table)
(setf (gethash key table) value)))
but that is a user code correctness issue, not a "will this break horribly" issues as the above points. |
While our current policy is not unreasonable, it makes doing something elementary -- eliminating strictly unsafe hash-table accesses from a codebase far harder than it should be.
I propose the following:
1. Hash-tables should be synchronized by default, so that portable library code has a prayer of doing the right thing. Code that cannot pay the overhead of synchronization can still request unsychronized tables explicitly.
2. Synchronized hash-tables need to be safe to modify while iteration is happening in another thread.
WITH-LOCKED-HASH-TABLE is still needed to make interning into a hash-table work right
(with-locked-hash-table (table)
(or (gethash key table)
(setf (gethash key table) value)))
but that is a user code correctness issue, not a "will this break horribly"-issue as the above points. |
|
