Re: [ jEdit-devel ] Threading in jEdit

[Shlomy R. <sre...@gm...>]

I can keep WorkThreadPool for a while, until all uses of it are
updated to work correctly. There is no sense, as far as I know, in
making AWT requests wait for other, unrelated non-AWT requests. There
is one problem that this can solve, and that is several asynchronous
requests running concurrently in non-AWT threads, with the AWT request
depending on all of them, which means it should run only once all of
them have finished. If some plugin uses WorkThreadPool to solve this
problem, then a mechanism for this needs to be implemented and the
plugin should be changed to use this mechanism. But some other current
uses of the WorkThreadPool do not need this and should be changed.

Shlomy

On Wed, Oct 8, 2008 at 9:58 AM, Ian Lewis <ian...@gm...> wrote:
> I too noticed this code when making a fix to the LispPaste plugin and
> thought it odd how it was working. I think your approach sounds like the
> right approach but keep in mind that it would break some plugins that are
> depending on how WorkThreadPool works, especially ones that do asyncronous
> calls to a web service or somesuch.
>
> Ian
>
> 2008/10/8 Shlomy Reinstein <sre...@gm...>
>>
>> I noticed that this class in jEdit is commonly used as the following:
>> Some request is queued to execute in a non-AWT thread (e.g. SideKick's
>> parsing of the buffer), then another request, that logically depends
>> on the completion of the first request, is queued to execute in the
>> AWT thread (such as the update of the SideKick tree with the results
>> of the parsing). The AWT request is queued independently of the first
>> request, but the WorkThreadPool ensures (or at least, it is supposed
>> to ensure) that the queued AWT requests do not execute before all
>> queued non-AWT requests have executed. This is, in my opinion, a
>> twisted approach, which also gives up some concurrency. I think the
>> right way to do it is to queue the AWT request for execution in the
>> AWT thread at the end of the non-AWT request. So the code for the
>> non-AWT request would queue the AWT one before returning. This way,
>> the AWT request does not have to wait for other, possibly unrelated,
>> non-AWT requests to complete.
>
>