Comment 1 Philipe Mulet 2003-05-12 06:32:55 EDT

The fact it would happen in background would not make it faster.

FYI, in Eclipse 3.0, we are thinking of forking certain long operations in a 
background thread. For instance, the entire build process would occur there.

Moving to platform as the build manager lives there.

Comment 2 Genady Beryozkin 2003-05-12 12:25:11 EDT

The delete operation will not run faster in the backgroud. However, the build 
can begin when the delete operation is still in process.

Comment 3 DJ Houghton 2003-05-14 11:22:14 EDT

Bug 36957 covers supporting background activities.

Moving to JDT/Core for comment on last originator annotation (a builder-
specific solution) and closure.

Comment 4 Philipe Mulet 2003-05-17 04:39:33 EDT

If the Java builder needs to clean the output folder, it would likely wait 
until it is empty before generating further files into it. If not, then it 
would become highly inconsistent.

Comment 5 Philipe Mulet 2003-05-22 11:34:55 EDT

Closing.

Comment 6 Genady Beryozkin 2003-05-22 17:37:15 EDT

I tried my approach, and it looks like the java builder is not confused 
by leaving entries in there. Also, it is possible to create a kind of 
"recycle bin" folder where the bin folder contents will go on clean operation.
The recycle bin will be emptied in a background thread.

Please take a look at the attached patch code (no recycle bin yet, but it 
works)

Thanks,
Genady

Comment 7 Genady Beryozkin 2003-05-22 17:38:36 EDT

Created attachment 4938 [details]
A patch to 2.1.1 stream that cleans the bin folder in the background

Comment 8 Philipe Mulet 2003-06-02 05:27:24 EDT

Kent - pls investigate

Comment 9 Kent Johnson 2003-06-02 10:42:47 EDT

This is an interesting idea but I have a few reservations.

1. Cleaning the output folder can generate core exceptions when resources 
cannot be deleted. The builder may be unable to rename the output folder 
because other processes outside of eclipse are actively browsing it. Also with 
a background thread, we would need to interrupt the main thread & delete the 
contents of the 'new' output folder + rename the old one back when a core 
exception happened. Increased complexity is something we're avoiding in the 
builder to reduce the 'hard-to-duplicate' PRs.

2. Cleaning the output folder is a small percentage of a typical full build. I 
believe a full build comes close to maximizing the machine so I doubt we'll be 
any faster by switching. Also the thread model in Java adds some overhead + we 
would need to constantly yield in the background thread to ensure the main 
thread is given priority. This could potentially slow us down on some JVMs with 
poor thread management.

Again its an interesting idea but I would prefer to wait until the 3.0 thread 
model story is out & we can evaluate our options in that context.

I guess I just not as annoyed by the message "Cleaning output folder..." as 
some users. ;)

Comment 10 Kent Johnson 2003-06-04 14:59:34 EDT

I'm going to close this since it looks like the builder will be run completely 
in a background thread as we move into the 3.0 world.

Thanks for the suggestion & the work.

Comment 11 Genady Beryozkin 2003-06-05 11:55:53 EDT

I'll wait to see how it works