xsl-list
[Top] [All Lists]

Re: [xsl] Re: [saxon] Questions about the `saxon:threads` extension attribute

2019-12-27 23:15:46
Thank you, Dr. Kay,

Is it too much to ask (for the benefit of the whole XSLT developers'
community and current + future Saxon users) for implementing the desired
behaviour in a future release of Saxon?  :)

1. Honour fn:unordered()  -- this will make it possible to do WaitAny().
The current behavior is equivalent to WaitAll() even when there is an
exception in one or more threads.

2. If one of the threads crashes, kill without waiting all remaining
threads -- this will make it possible to implement cancellation on external
event. There are obvious benefits of freeing one or more cores that are
busy with the threads whose results, regardless of how long it takes to be
produced, will be ignored

Happy Holidays,
Dimitre

On Fri, Dec 27, 2019 at 5:20 PM Michael Kay mike(_at_)saxonica(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

Quite a difficult question to answer accurately because I haven't looked
at the code for a while and the logic isn't all in one place; it also
depends on understanding the behaviour of the underlying Java services that
we rely on, notably the ExecutorService.

Q1. Firstly, calling fn:error() is exactly the same as any other dynamic
error. We throw an XPathException; this is caught by the
MultithreadedContextMappingIterator, this invokes
ExecutorService.shutdown() which prevents new tasks being accepted but
allows existing tasks to finish. A "task" here is the processing of a
single item in the for-each selection.

Q2. There are two cases to consider with try/catch: where the try/catch is
local to one thread (within the multi-threading for-each), and where it is
outside the multithreading for-each. In the first case there should be no
effect on other threads. In the second case the xsl:for-each fails as a
whole, and the error is caught as a whole.

Q3. We don't take any account of fn:unordered(); we always respect the
ordering.

This is complicated by the fact that xsl:for-each may be executed in
either pull or push mode. Push mode is generally used when writing to a
tree, pull mode when evaluating (non-document) variables and functions. In
push mode you can never see any results until they are complete. In pull
mode, items are delivered as soon as they are available; so a reference to
$var[1] may return a result even though $var[2] has not yet been computed,
and this applies to multithreaded execution just as much as to
single-threaded execution. Multithreading complicates it, because $var[2]
may be computed before $var[1], but we won't allow you to see $var[2] in
that situation; it will be sitting in a queue somewhere waiting to be added
to the result.

Michael Kay

On 27 Dec 2019, at 05:18, Dimitre Novatchev <dnovatchev(_at_)gmail(_dot_)com> 
wrote:

The questions below are essentially for Dr. Kay, though anyone interested
and able to shed light on these is welcome.

I need this information, because it seems not to be available in the Saxon
documentation.


*General setup*:  We have multi-threaded processing specified by
saxon:threads=”2”


*Q1*. What will happen if *thread1* calls the *fn:error*() function? Will
the execution of *thread2* be terminated immediately/promptly, or will it
continue executing until the end of its processing?


*Q2*. Same as Q1 above, but the multi-threaded processing is enclosed in
<xsl:try> and the error thrown by the *fn:error()* function is caught in
the `<xsl:catch>` child of `<xsl:try>`. Then `<xsl:catch>` produces a
normal value (the error is not re-thrown) – will the 2nd thread be
suppressed or will it continue executing until the end of its processing?


*Q3*.  This time there is no error thrown. Can we access the result of
just one of the threads (whichever finishes first) even before the other
thread has finished? For example, if the results of the two threads are in
the sequence constructor of an `<xsl:variable
select=”vmultithreadingResults”>`, is it possible to access the result of
the first finished thread in an expression like:

fn:unordered($vmultithreadingResults)[1] ?


--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--
<Prev in Thread] Current Thread [Next in Thread>