> The thread has a simple task. It runs a timer which monitors a file on
> the File System for modifications. If modifications are made then the
> thread is said to be "complete" and we can close the thread by
> 'return;' within the run method. Then the next iteration can start and
> repeat the process for 'n' iterations.

Signature
Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
On Oct 19, 9:33 am, Lothar Kimmeringer <news200...@kimmeringer.de>
wrote:
> > The thread has a simple task. It runs a timer which monitors a file on
> > the File System for modifications. If modifications are made then the
[quoted text clipped - 31 lines]
> Always remember: The answer is forty-two, there can only be wrong
> questions!
Yes, but doesn't that mean the thread will wait a maximum of 1 second
for the "task" to complete before going to the next iteration? What if
the time needed to make the modifications can be dynamic? Could happen
in 2 seconds...3 seconds later...or even 10 days later?
Thanks for your reply.
/sqad
Gordon Beaton - 19 Oct 2007 18:05 GMT
> Yes, but doesn't that mean the thread will wait a maximum of 1
> second for the "task" to complete before going to the next
> iteration? What if the time needed to make the modifications can be
> dynamic? Could happen in 2 seconds...3 seconds later...or even 10
> days later?
The point is that you use threads when you need to perform some action
concurrent to the caller, i.e. so that the caller can continue with
other work while the thread runs.
If your caller simply waits for the thread to finish, it could have
performed that work itself; the thread wasn't necessary.
That said, the caller can wait for the thread to finish by calling
t.join(), where t is a reference to the running thread.
If you simply want to delay for some time, then call Thread.sleep(),
just like that, without starting a thread.
/gordon
--
sqad - 19 Oct 2007 21:34 GMT
> > Yes, but doesn't that mean the thread will wait a maximum of 1
> > second for the "task" to complete before going to the next
[quoted text clipped - 18 lines]
>
> --
Ahh understood and solved within the caller thread itself. I'll bake
in a worker/producer solution at a later time so I can run concurrent
threads. Thanks for the clarification, guys.
/sqad