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
--
MichaelDaum on 10 May 2005, 14:33:06