Re: An Executor-like structure providing more than threads

Holla yalls,

This is a slightly confused question, for which i apologise. I've been
on a minor quick-and-dirty hacking run, and haven't really thought this
through properly.

An Executor is a thing that has a pool of Threads, accepts a stream of
Runnables (or Callables), pairs them up one after the other with
Threads, then sends the pairs off together to do some work, and accepts
the Threads back afterwards.

What if the resource needed to perform a task, the thing you wanted to
maintain a limited pool of, reuse, and provide shared access to, was
more than a Thread?

In my case, it was a Downloader, which was a Thread plus an instance of
Apache's HttpClient and a buffer. The tasks were URLs to download. URLs
come in, are assigned to a Downloader which downloads them, and when the
download is done, the Downloader goes back to be assigned another URL.

I could have written this with the Downloaders being the active party,
going to a queue of URLs, pulling one off, downloading it, then going
back for another. Or i could have put Downloaders in a pool, and had the
submission mechanism pull them out and hand URLs to them. But i really
wanted to be able to use all the cool stuff in ExecutorService, like
getting Futures and having orderly shutdown, and a properly controllable
thread pool and so on. So what i did was subclass Thread to add the
other bits (the HttpClient and so on), and then, in the tasks, do
something like:

((DownloadThread)Thread.currentThread()).getHttpClient()

And so on. I thought that was quite clever, although it is clearly also
entirely bletcherous.

Any thoughts? What's the right way to do this?

tom