/--- On Fri, Aug 18, 2000 at 06:19:43PM -0400, Chaim Frenkel wrote:
| I don't think you should even attempt to version/transaction
| protect
| a tied variable. Anything that leaves the memory or could leave
| the
| memory (e.g. socket write) should probably not be versioned.
|
| Unles
I don't think you should even attempt to version/transaction protect
a tied variable. Anything that leaves the memory or could leave the
memory (e.g. socket write) should probably not be versioned.
Unless the tied variable somehow is able to tie itself into the
transaction manager. It is up for
/--- On Thu, Aug 17, 2000 at 06:17:51PM -0400, Chaim Frenkel wrote:
| Though this is a tough problem especially in the face of threads.
| Though versioned variables may be able to remove most of the
| locking
| issues and move it down into the commit phase.
Yes, but you can give strange
Think about deadlock, extra overhead, and time taken to take the lock.
If a set of variables should be locked as a unit only one mutex should
be assigned.
What to do about overlapping members
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> I wrote a transaction-enabled data
I wrote a transaction-enabled database in perl 5, using fork()
for my multithreading and flock() for my mutexes. It continues
to work just fine.
Threading gives us mutexes. Are you just saying that
every variable should have its own mutex, and perl's = assignment
operator should implicitly se
Nice thought.
Actually, this or something like this might be helpful in maintainting
invariants in the face of exceptions.
Though this is a tough problem especially in the face of threads.
Though versioned variables may be able to remove most of the locking
issues and move it down into the commi
> We need to get a new keyword for defining such a variable, I think
> "transaction" is too long, we could use "safe" for this reason.
The proposal looks good. But isn't this more a language issue at this
point? Seems like we'll have to figure out the behavior we want first.
Also, "safe" i
