@hubbcaps CherryPy is already threaded server, but beware of GIL, which prevents Python from having more than one active thread at a time. You may want to look at RQ or Celery for scheduling long-running tasks in separate jobs.
Also, there's a pool of threads in CherryPy, which is configurable, so if you enlarge amount of them, you might be able to serve more simultaneous requests. But if you'll spawn this long-running task inside each of worker threads, pool will run out of workers again.
I'll look into those suggestions @webknjaz, I appreciate it. I'm pretty confident it should be alright in it's current state though, although I'm sure someone will prove me wrong once I start getting some users. The app is a comic book reader, and really the only function that I need running in the background is the scanning of the comics library which can only be kicked off by the admin of the web app and any new requests for the same scan while one is running are quickly halted by virtue of the db lock I have in place. Everything else handled by the web app is very quickly returned and handled, so I think it should all be ok for now that I have the manual kick off being pushed immediately to another thread and returning normally to the initating request on the main thread.