Bug #2204: Nested multithreaded xsl:for-each - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2204

closed

Nested multithreaded xsl:for-each

Added by Michael Kay about 10 years ago. Updated about 9 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Saxon extensions

Sprint/Milestone:

9.6.0.2

Start date:

2014-10-29

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.6

Fix Committed on Branch:

9.6

Fixed in Maintenance Release:

9.6.0.2

Platforms:

Description

Saxon-EE allows an xsl:for-each instruction to operate in multithreaded mode by specifying the extension attribute saxon:threads="N".

This fails (typically causing the VM to hang) if several concurrent executions of the same multithreaded xsl:for-each instruction occur in parallel.

This might happen because the multithreaded xsl:for-each is nested (statically or dynamically) in another multithreaded xsl:for-each, or because the stylesheet containing the multithreaded xsl:for-each instruction is itself executed several times in parallel, for example by creating several XsltTransformer instances from the same XsltExecutable.

The problem has been re-created in a reproduceable test case, and a patch has been tested on the 9.6 branch.

Actions

Copy link

Updated by Michael Kay about 10 years ago

Status changed from New to Resolved

Now fixed on the 9.5, 9.6, and 9.7 branches.

The problem was that two variables (maxThreads and executionPool) evaluated during the course of evaluating the xsl:for-each instruction are held in instance-level variables of the MultithreadedForEach class, which is an expression class and therefore part of the compiled stylesheet, which is supposed to be threadsafe. It proved easy to change these to local variables held on stack.

The test case used was an adapted version of XSLT 3 test case catalog-005, adapted to put saxon:threads on two nested loops. No permanent test case has been created.

Actions

Copy link