I hate to bring it up after 50+ responses over 4 days, but . . .
Did anyone ever actually run my little test?
On something other than my UV10.2/Win? Unix? Before UV10.2?
Knowing that would help me assess the size & age of our problem.
I still think that in times past, a waiterfor a lockvia WRITE or
DELETEwould show up at the 3rd section of LIST.READU EVERY, even as the
typical READU (or FILELOCK, RECORDLOCKU) does.
The original test was request was this:
On 10/24/2011 4:11 PM, Charles Stevenson wrote:
UV 10.2.10 on Windows is behaving differently from what I recall.
Are my expectations out of line?
Suppose Session A holds a readu lock; and Session B attempts a WRITE
to same record withOUT!!! 1st explicitly getting the readu lock.
Session B waits for Session A to release the lock before writing the
record.
While Session B is waiting, does it show up as a "waiter" in
LIST.READU EVERY?
I expected so, but it doesn't.
Session A Session B
_____________________________ ___________________
1A. ED VOC DUMMY
(this sets the readu lock.)
2A. (stay in editor) 2B. run this:
01: OPEN 'VOC' TO F ELSE STOP
02: ***READU REC FROM F, 'DUMMY'
ELSE NULL
03: WRITE '' TO F, 'DUMMY'
3A. Within ED:
XEQ LIST.READU EVERY
If I UN-comment line 2, LIST.READU EVERY shows something like this:
Active Read Waiters: Owner Waiter
Device.... Inode.... Userno Userno
746117947 232860913 6116 3396
But when I comment out line 2, LIST.READU is silent.
I have not yet explored what the deadlock daemon does.
TIA,
cds
P.S. Yes, yes, "Bad Form", "Legacy Software", 20 min wait is
configurable, . . . we can talk later.
"Later" is already past. I'm not talking about that P.S. again!
thank-you,
cds
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
