Concurrency Safety

Description

XCDG does not guard against concurrent calls to libcdg.

It is possible for two events in the tree editor to trigger two calls to libcdg which are illegal to call concurrently. For instance, quick right clicks on two labels can cause two different calls to parseOptimizeLabel to be active at the same time. Since both share global variables, this leads to Segmentation faults as the second call finds its invariants mysteriously violated. (Even if it did not crash, the results of both computations would likely be wrong.)

As a stopgap, the tree editor now refuses to accept a second `optimize' event before the first one has terminated. This has the unintuitive downside that mouse clicks are silently ignored. Also, the problem is not limited to the optimizing right clicks; on a slower computer, a faster user, or a longer sentence the same could happen with almost any editing action that calls libcdg.

Rather than littering the code with manual locking, editing actions that call libcdg should arrange for themselves to be put onto an execution queue so that no events are lost, but each call is safely executed separately.

Reproduce:

 
  cd /data/corpus/ccc/xxl
  xcdg -s showparse xxl.cdg xxl-s11
  [right-click both `REL' labels in quick succession]

Comments

-- MichaelDaum on 21 Feb 2005, 11:29:31

increased severity to "crash"
-- MichaelDaum on 10 May 2005, 14:33:06

 

 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback