Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 346541

Summary:	CompositeUIProcess
Product:	[RT] Riena	Reporter:	Christian Campo <christian.campo>
Component:	Look And Feel	Assignee:	Project Inbox <riena.core-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	nobody, Stefan.Liebig, stephan.mann
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Christian Campo

2011-05-19 16:36:29 EDT

Every now and then we experience that people want to run multiple UIProcess but like to join them back together at the end.

So what I coined here ComplexUIProcess is actually a subclass of UIProcess with new methods.

So at any given time in the run method of the UIProcess you could call something along the lines of "fork(new Runnable())" (maybe fork is not a good name or maybe it is).
The Runnable is then started in a seperate thread and runs in parallel.

Its imporant that once the run method is over, the ComplexUIProcess waits for all "forked" Runnables before it calls the finalUpdateUI method.

Comment 1 Stephan Mann

2011-05-20 03:40:28 EDT

+1
This is a use-case that should be as easy as a "normal" asynchronous job.

fork() is a good name because it refers to a pattern known to many programming languages:
http://download.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html
http://linux.die.net/man/2/fork

On the other hand I would suggest finding a more descriptive name for the class. Something like ForkableUIProcess or CompositeUIProcess.

Comment 2 Stefan Liebig

2011-05-20 04:16:45 EDT

Yeah, the current "work" name is scary!  Uh, its complex - I won´t use it ;-)
How about a name for the UIProcess that unveils what it is capable of?
Maybe something like the afore mentioned (comment #1) fork/join if it fits the semantics?

Comment 3 Christian Campo

2011-05-20 04:23:58 EDT

CompositeUIProcess was my other preference for the workname so I change it right away.

Comment 4 Nobody - feel free to take it

2011-05-20 04:30:07 EDT

First of all i like the idea to provide any kind of convenient API. At the moment we can do this, but we need to extend the API.
But do we really need a ComplexUIProcess? I think we first have to work out a concept of a tree of processes which partly depend on each other and come up with a more generic solution .. or better a concept.

Notes: 
- Every process should have the ability to "fork". But in my opinion while forking we should not break the eclipse jobs concept by "starting threads".
- Eclipse jobs API allready provides a "join" API and as UIProcess uses jobs internally we should use it.
- Eclipse jobs allow grouping of jobs ( join group? )

Comment 5 Nobody - feel free to take it

2011-05-20 04:31:11 EDT

I agree 'the current "work" name is scary'