Re: codec - thread safe
> Date: Mon, 8 Oct 2007 17:01:02 +0200 > From: =?iso-8859-1?Q?J=F6rg_Schaible?= <[EMAIL PROTECTED]> > > > The java.util.concurrent backport > > http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this > > kind of use. > > I know this, but I doubt that we wanna start to depend Apache common > components on it ;-) Agreed; I, like you, was merely suggesting to what Commons consumers might do to deal with non-threadsafe codecs. > - Jörg -- David J. Biesack SAS Institute Inc. (919) 531-7771 SAS Campus Drive http://www.sas.com Cary, NC 27513 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: codec - thread safe
> Date: Mon, 8 Oct 2007 16:23:59 +0200 > From: =?iso-8859-1?Q?J=F6rg_Schaible?= <[EMAIL PROTECTED]> > > David J. Biesack wrote on Monday, October 08, 2007 3:02 PM: > > >> Date: Sat, 6 Oct 2007 23:31:19 -0500 > >> From: "Qingtian Wang" <[EMAIL PROTECTED]> > >> > >> Well, it's pick-your-poison kind of a deal. Either block on one > >> instance and take a performance hit, or burn up the memory with lots > >> of instances. > > > > Why not compromise? Create a ThreadPoolExecutor ... > > Because it runs on JDK 1.3? The java.util.concurrent backport http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this kind of use. > However, that's the reason why I argumented not to promise thread-safety for > any codec and provide synchronization wrappers or a user might take the pool > approach ... which is quite easy with JDK 5 as you've provided here :) I think it makes a lot of sense to document the thread safety attributes of Commons libraries. > - Jörg -- David J. Biesack SAS Institute Inc. (919) 531-7771 SAS Campus Drive http://www.sas.com Cary, NC 27513 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: codec - thread safe
> Date: Sat, 6 Oct 2007 23:31:19 -0500 > From: "Qingtian Wang" <[EMAIL PROTECTED]> > > Well, it's pick-your-poison kind of a deal. Either block on one > instance and take a performance hit, or burn up the memory with lots > of instances. Why not compromise? Create a ThreadPoolExecutor of some reasonable size and submit a FutureTask to run the encode or decode, and then do a future.get() when the value is needed. You might even get some concurrency if you can start the encode, then continue doing other work until you need the result. -- David J. Biesack SAS Institute Inc. (919) 531-7771 SAS Campus Drive http://www.sas.com Cary, NC 27513 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
