Project

General

Profile

Bug #6740

« Previous | Next »

re-enable FRAME_LOCK in annotations/embedded_attribute_assign_rewrite and determine when the lock can be released because of an realization event

Added by Constantin Asofiei over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version:

History

#2 Updated by Constantin Asofiei over 1 year ago

In #6726, it was measured ~10k calls of LT.flushEnqueuedWidgetAttrs. Some of these calls are part of a CREATE <widget> ASSIGN ... statement, where the ASSIGN has lots of widget attribute assignments.

The code in annotations/embedded_attribute_assign_rewrite.rules which at some point was bracketing the attr assignment in frame lock/unlock was removed at some point, with a comment that:

         <!-- The following code was commented out because assignments in CREATE..ASSIGN should be
              executed sequentially rather than is a batch. We should support that in the middle
              of assignment process frame may become realized and some of the following
              assignments may fail with "widget is already realized error". -->

My thinking is that if an attribute which produces realization events gets assigned, the frame lock should be released immediately, to prevent the bug in the comment above. This may allow reducing the number of widget attr flush calls to the client-side.

Also available in: Atom PDF