On Thu, Dec 15, 2016 at 4:06 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Mark, > > On 12/15/16 2:44 PM, Mark Thomas wrote: > > On 15/12/2016 19:35, Christopher Schultz wrote: > >> John, > >> > >> On 12/14/16 10:01 PM, John D. Ament wrote: > >>> I was feeling ambitious so I gave this a shot. Here's what I > >>> changed: > >>> https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d > 3c > <https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d3c> > >> > >>> > d1e750b48498ff2 > > > > That was pretty much what I was thinking. > If you want it, let me know. I can provide a patch. I'm not sure what tests to add, other than verify no extra threads were created. I need to setup a bugzilla account too. > > > >> My > >> > >> tack was going to be to create an ExecutorService that didn't > >> dispatch. That way, less code has to change. > > > > Seems like more work. And doesn't solve the original problem of the > > main thread holding a lock. > > No, it won't hold a lock. The (Abstract)ExecutorService just > dispatches to the execute(Runnable job) method which can simply be: > > job.run() > > In that case, only one thread is ever involved: the thread that > submitted the job. > The problem is that tomcat is expecting a ThreadPoolExecutor. It may make sense to wrap it in a delegate that just handles the calls you need, since you're only calling one method on the executor. That would simplify this logic as well. > > >> The problem with that approach is that, technically, the thread > >> count can change for a variety of reasons and it should behave > >> correctly at the time the contexts are started/stopped. > >> > >> I'd be interested in some comments on changing the behavior of > >> Tomcat based upon the documentation of startStopThreads. For a > >> value of "1", it explicitly says that 1 thread will be used. I'd > >> be surprised if Tomcat were not to use a single (separate) thread > >> rather than the main thread. > >> > >> Thing about this use-case: you have an embedded scenario where > >> you want to launch Tomcat and you expect the start() call to > >> return fairly soon so you can continue doing whatever you wanted > >> to do. But instead of using the "1 thread" to start all the > >> contexts, it's using the current thread and blocking you. > > > > That isn't what happens. The main thread always blocks until all > > the container start threads have completed. > > Oh, well, then my use-case seems moot. Or, at least, no > currently-running code will expect that behavior. > > >> I'm wondering if we need to invent a new magic number for this. > >> Unfortunately, 0 is already taken. Perhaps we could use a > >> non-numeric value for this special case. > > > > I don't see a need for that. > > I could imagine a need for that behavior, but there's an easier way > for client code to handle it: launch Tomcat.start() from a separate > thread. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJYUwXHAAoJEBzwKT+lPKRYYNwP/36ZY+6XsIU2GgsihjHxCIPe > kixjLj6GZXtc8mhoBWRVg3D16dhG62PhCSt813JIKFZMQQMd/zjuYFV6qqkZlv4D > 4k0+wxVGLC9oWZA0awuAfWOiAYeHDUEe6Rwr67oUrmpxNcanvv9uk0URxYWEZjzj > YS5ogX/lxJ/EuYIxz2aOptQ8q6W/fARQTsAdiIL3KWy2kjrDvWH/8V46oQxUwdXJ > ilqnMPvCkTwAyKqeCug4bsDr4V/Xk7gjdqttb0qlntfLYay1WmWx1mAnTCD77V/H > 6iCSviICy7dFrif4dfTHJ8SS2a8WxXMPR+ng8daCCaZE4GcNqs7bp1z254626xSw > f/Ob2JPlD8aAsjM6WwAhtdlsE/0DzwkKm0Ski3ejt/A2Uh8V5KfaECyNgg1dRoak > czJxxegVyUotkUjx7nL8nqW3dwb2wFJjhUVb/KKiZrl6TC8ME0Ix8UvcCx+Ldaoe > KDVyJjqDSvEECwHLkCUTMbdX0wCJ2qMoH3ULDXMIEHpot9tkDQEa8iUAC9oS7dP0 > zUmPY9syYwTBueRT0taSnpumrZ+iZkQIGPGEfX52kf90O9e8uGTFFSBMCoPpwI0M > OfoH6A7g0I69tHiO05fFicj16Rf5BqoNQvKfn8CCzEJA41Uek9yTETGdlHUcbIZy > NwWg49KyTN9G3o851TmW > =QY5c > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
