On Jul 24, 2006, at 12:00 PM, Meeraj Kunnumpurath wrote:
Jeremy,
Apologies if you have received my earlier email (my internet mail
account doesn't seem to work always)
I think this is one of them - the previous mail I have was at 10:11AM
PDT.
Executors.newFoxedThreadPool() creates a thread pool backed by an
unbounded queue. This means even when all threads are in use, work
won't
be rejected. In terms of when and where the workAccepted method is
invoked, can we say is an implementation detail, as long as the
order in
which the callbacks are executed are guaranteed. Alternatively, we
could
wait on workAccepted callback on the monitor for the work item before
calling workStarted.
I agree the order of callbacks will be correct. However, if there is
significant delay in scheduling the work the latency of the callbacks
would be unexpected - as a client, I would expect workAccepted to be
called before the scheduling delay (on enqueue) and workStarted after
the delay (on dispatch).
Invoking the callback whilst holding a monitor is normally a bad idea
but in this case I think it should be safe enough. There may be
problems if the workAccepted callbacks run too long but perhaps we
just put that down to user error.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]