Hi Tobias, On Fri, Dec 6, 2013 at 1:39 PM, Tobias Pietzsch <pietz...@mpi-cbg.de> wrote:
> Hi, > > On Dec 6, 2013, at 7:28 PM, Johannes Schindelin < > johannes.schinde...@gmx.de> wrote: > > > Hi Lee, > > > > On Fri, 6 Dec 2013, Lee Kamentsky wrote: > >> > >> On Fri, Dec 6, 2013 at 10:10 AM, Tobias Pietzsch <pietz...@mpi-cbg.de > >wrote: > >> > >>> Problem: Did anyone think about the possibility of deadlocks? > >> > >> Nice catch, Tobias > > > > Does anybody have a different reaction than "Oh well, that's right, we > > cannot use the ExecutorService, then, but instead need to adapt the > > ThreadService so it handles this one right"? > > Here, I have a different reaction: > As I pointed out, this has been done exactly right in Java 7 Fork/Join > framework (by people who presumably put more thought and experience into it > than we could). > If the majority insists that we reimplement something similar, then at > least let us use the same interfaces. > > It looks to me like a computation has to know whether or not it is being run inside a ForkJoinThread. If so, it calls ForkJoinTask.invoke() to complete the computation and if not it calls invoke on the pool. I don't think this completely solves our problem - if X calls Y which invokes Z on the thread, then Z should invoke on the pool, but if X invokes Y which invokes Z, then Z should invoke on the ForkJoinTask. The mechanism should make its decision based on the thread identity and not burden the framework with keeping track of where it is. So I say that they didn't get it right and that we can do better. > best regards, > Tobias > > > > > Ciao, > > Dscho > > > > -- > > -- > > Please avoid top-posting, and please make sure to reply-to-all! > > > > Mailing list web interface: http://groups.google.com/group/fiji-devel > > > > --- > > You received this message because you are subscribed to the Google > Groups "Fiji-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to fiji-devel+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > >
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
