Hi Piotr,
> I don't think this would help. If a thread iterates over a collection while
> another thread is modifying it, you'd get ConcurrentModificationException
> anyway.
Just to be sure of this ... the code returns a new Iterator so we should be ok.
public Iterator<URL> iterator() {
return new Iterator<URL>() {
private Iterator<URI> iterator = resourceCache.iterator();
...
Some info on Iterators and multithread even here (just for reference):
http://www.oodesign.com/iterator-pattern.html
> Is this iterator ever used somewhere? If it is, we have to solve it somehow
> differently. Nevertheless making just puts and gets synchronized solved the
> issue at least for us - we don't encounter any crashes while starting the app.
Ok, so I think all should be good ...
> The scenario that was causing this was the following:
>
> Thread one: load window 1 from BXML
> Thread two: load window 2 from BXML
> Thread three: load window 3 from BXML
> Thread four: load window 4 from BXML
> Join threads
> In GUI thread - open all the loaded windows
This could be a very interesting new Tutorial / Sample, if you have
some time it would be great to prototype something.
Or if someone of us has some time ... if possible I'll try in next
days, but if you have something ready to use please tell me.
> It is important for us to make it work (stable), because on a multicore
> machine it improves loading windows by about 40% (not perfect, but visibly
> faster).
Yes, I understand, and it's a major problem in all modern software ...
better usage of multicores ... and it's one of the reasons why I like
so much Scala :-) .
> BTW: Have you ever optimised pivot for faster startup times? The first thing
> we noticed when we switched from Swing is that Pivot was somehow slower to
> start up. This is worrying me - now it is not a problem it the user waits for
> 1 second to load the app (I'm talking about warm start up), but if in future
> the gui gets bigger...
No, I don't think none of us has even done something like this ... an
in-depth look with a Profiler would be welcome (mabye even starting
with the NetBeans profiler, and/or VisualVM). An issue for 2.1 on this
could be add.
> The competition using JavaScript doesn't have that problem. :( Maybe there
> are some possibilities to limit the amount of classloading or make some
> things more lazy?
Yes, I know ... maybe for 2.1 we could really try to do something, but
before someone of us should do some analysis with a profiler, to
better understand if/where we can improve ...
Bye,
Sandro
