Changes

Jump to navigation Jump to search
136 bytes added ,  11:27, 4 February 2017
|-
| '''Summary'''
|Indicates if the evaluation of a an already running job with the specified {{Code|$id}} has finished. As the ids of finished jobs will usually be discarded, unless caching is enabled, the function will also return <code>true</code> for unknown jobs.
* <code>false</code> indicates that the job id is scheduled, queued, or currently running.
* <code>true</code> will be returned if the job has either finished, or if the id is unknown (because the ids of all finished jobs will not be cached).
|-
| '''Summary'''
|Cancels Triggeres the execution cancelation of a job with the specified {{Code|$id}}, drops the cached result of a query, or cancels a scheduled job. Unknown ids are ignored. All jobs are gracefully stopped; it is up to the process to decide when it is safe to shut down.
|}
|-
| '''Summary'''
|Waits for the completion of a job with the specified {{Code|$id}}. If the function is called with the id of a queued job, or repeatedly executed job, it may stall and never terminate.
|-
| '''Errors'''
};
</pre>
* The following query demonstrates how the results of an asynchronously executed query can be returned within the same query. Please remember that this is not the common way how these functions will be used in practice:
<pre class='brush:xquery'>
let $query := jobs:eval('(1 to 10000000)[. = 1]', map{}, map{ 'cache': true() })
return (
hof:until( function($f) { jobs:finishedwait($query) }, function($f) { prof:sleep(10) }, () ),
jobs:result($query)
)
</pre>
Please note that this query can easily cause a deadlock if the asynchronously executed query will be queued. In practice. In practice, you should avoid this pattern and resort to [[XQuery Module#xquery:fork-join|xquery:fork-join]] if you want to do things in parallel.
|}
Bureaucrats, editor, reviewer, Administrators
13,550

edits

Navigation menu