<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Curtis,<div><br></div><div><blockquote type="cite"><div dir="ltr"><div>> [SJC]<span style="font-family: arial, sans-serif; font-size: 13px; "> is absolutely not the right thing if you are building a library in my opinion.</span></div><div><span style="font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span style="font-family: arial, sans-serif; font-size: 13px; ">I strongly disagree; SJC was created to benefit SCIFIO, and it has done so tremendously. I can elaborate on this if you like, but suffice to say that even libraries have configuration and state and services that they need to provide, and a unified context is an excellent way to do this. If you instead rely on statics, you will create something that cannot be extended. We learned this from painful experience with Bio-Formats!</span></div></div></blockquote></div><div><div dir="ltr"><div><span style="font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span style="font-family: arial, sans-serif; font-size: 13px; ">Yes, could you please elaborate on this!</span></div><div><span style="font-family: arial, sans-serif; font-size: 13px; ">Maybe I should say that I have just recently (two days ago to be honest) started to seriously get into scijava-common and I like it very much so far. </span><span style="font-family: arial, sans-serif; font-size: 13px; ">But I still don't see where it would benefit imglib2 core. </span><span style="font-family: arial, sans-serif; font-size: 13px; ">I would like to have imglib2 be as close to purely functional as possible, no state, no side effects. As much as possible, at least.</span></div><div><span style="font-family: arial, sans-serif; font-size: 13px; ">Could you please explain where SCIFIO benefits from being stateful and where being stateful would probably help imglib?</span></div><div><span style="font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span style="font-family: arial, sans-serif; font-size: 13px; ">best regards,</span></div><div><span style="font-family: arial, sans-serif; font-size: 13px; ">Tobias</span></div></div></div><div><br><div><div>On Dec 6, 2013, at 7:52 PM, Curtis Rueden <<a href="mailto:ctrueden@wisc.edu">ctrueden@wisc.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi all,<br><div><br></div><div>After sleeping on it, I do not think SJC ThreadService is actually the way to go for providing better threading configuration of algorithms. But unlike Tobias, I do *not* think this is because SJC contexts are burdensome. Specifically, in response to Tobias's comment:</div>
<div><br></div><div>> [SJC]<span style="font-family:arial,sans-serif;font-size:13px"> is absolutely not the right thing if you are building a library in my opinion.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I strongly disagree; SJC was created to benefit SCIFIO, and it has done so tremendously. I can elaborate on this if you like, but suffice to say that even libraries have configuration and state and services that they need to provide, and a unified context is an excellent way to do this. If you instead rely on statics, you will create something that cannot be extended. We learned this from painful experience with Bio-Formats!</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Anyway, the reason I think SJC ThreadService is wrong for this use case is due to another bullet point I mentioned earlier:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><div>> Easy to override threading behavior on a case-by-case basis</div><div>> (i.e., pass different ExecutorServices to different algorithms).</div>
</div><div><br></div><div>That is, SJC services are singletons, intended to store state for the application context. The threading configuration for running an algorithm might be different than that for another algorithm running in the same context. We need to be able to configure it individually. While ThreadService might be able to serve as a sensible default configuration (i.e., "just use SJC's ExecutorService by default"), it should not be forced on every algorithm.</div>
<div><br></div><div><div>> As I pointed out, this has been done exactly right in Java 7 Fork/Join</div><div>> framework (by people who presumably put more thought and experience</div><div>> into it than we could). If the majority insists that we reimplement</div>
<div>> something similar, then at least let us use the same interfaces.</div></div><div><br></div><div>I agree that it would be great if we could use something that has been vetted by the greater Java community. However, this makes porting to non-JavaSE-7 platforms much more difficult. Tobias, I know you pointed out some java.util.concurrent leakages into ThreadService -- we weren't being overly careful about it yet -- but my point stands that SJC has the potential to make those sorts of ports easier if we put effort into it. More Jenkins builds against alternative Java implementations would be a great start toward that.</div>
<div><br></div><div>Anyway, it's not that I *want* to reimplement something similar to Java 7's Fork/Join... it's that I don't have a good alternative if we also want to support those other scenarios. One possible compromise would be design our own agnostic interface, and provide an implementation in its own module which uses Java 7's Fork/Join. That way, it will be possible to provide an alternative implementation on platforms which don't support it. This sort of interface-driven extensible design is *exactly* what SJC seeks to make possible with its plugin framework.</div>
<div><br></div><div>Regards,</div><div>Curtis</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 6, 2013 at 12:39 PM, Tobias Pietzsch <span dir="ltr"><<a href="mailto:pietzsch@mpi-cbg.de" target="_blank">pietzsch@mpi-cbg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On Dec 6, 2013, at 7:28 PM, Johannes Schindelin <<a href="mailto:Johannes.Schindelin@gmx.de">Johannes.Schindelin@gmx.de</a>> wrote:<br>
<br>
> Hi Lee,<br>
><br>
> On Fri, 6 Dec 2013, Lee Kamentsky wrote:<br>
>><br>
>> On Fri, Dec 6, 2013 at 10:10 AM, Tobias Pietzsch <<a href="mailto:pietzsch@mpi-cbg.de">pietzsch@mpi-cbg.de</a>>wrote:<br>
>><br>
>>> Problem: Did anyone think about the possibility of deadlocks?<br>
>><br>
>> Nice catch, Tobias<br>
><br>
> Does anybody have a different reaction than "Oh well, that's right, we<br>
> cannot use the ExecutorService, then, but instead need to adapt the<br>
> ThreadService so it handles this one right"?<br>
<br>
</div>Here, I have a different reaction:<br>
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).<br>
If the majority insists that we reimplement something similar, then at least let us use the same interfaces.<br>
<br>
best regards,<br>
Tobias<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Ciao,<br>
> Dscho<br>
><br>
> --<br>
> --<br>
> Please avoid top-posting, and please make sure to reply-to-all!<br>
><br>
> Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel" target="_blank">http://groups.google.com/group/fiji-devel</a><br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Groups "Fiji-devel" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:fiji-devel%2Bunsubscribe@googlegroups.com">fiji-devel+unsubscribe@googlegroups.com</a>.<br>
> For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank">https://groups.google.com/groups/opt_out</a>.<br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></body></html>