> My understanding of send and send-off, is that with send-off a new
> thread outside the thread pool is used to run the agent action.
Actually a different kind of thread pool is used for send-off. It is a
cached thread pool obtained from Executors.newCachedThreadPool(),
while send uses a thread
Tom,
> Actions given to an Agent are queued, so the action created via send-
> off won't execute until the current Action completes.
Thanks to you and Stuart for the explanation. If I'd only re-read the
agents section of the documentation first, I wouldn't have needed to
bother the group with th
Hi,
On 30 Okt., 12:43, Tom Davies <[EMAIL PROTECTED]> wrote:
> > Then every iteration of ant behaviour (and evaporation etc.) creates
> > a new thread, right? This implies that an agent is not forever bound
> > to the same thread. Nor is a thread bound to one agent, as otherwise
> > one cou
On Oct 30, 7:14 pm, Konrad Hinsen <[EMAIL PROTECTED]> wrote:
> Then every iteration of ant behaviour (and evaporation etc.) creates
> a new thread, right? This implies that an agent is not forever bound
> to the same thread. Nor is a thread bound to one agent, as otherwise
> one could iter
On 29.10.2008, at 16:20, Stuart Halloway wrote:
> (1) *agent* is set thread locally whenever a thread is an agent
> action. It's all in the Java code, grep for AGENT
OK, that's like I guessed then.
> (3) send uses a thread pool that you should not assume you control, so
> blocking for e.g. I/O
On Oct 30, 12:14 pm, "Jim Menard" <[EMAIL PROTECTED]> wrote:
> I was looking at the same code today. My question is slightly
> different. In the code
>
> (defn evaporation [x]
> (when running
> (send-off *agent* #'evaporation))
> (evaporate)
> (. Thread (sleep evap-sleep-ms))
> nil)
Hi Jim,
send-off is never immediate. It schedules a function for execution
later. The call to send-off queues execution of the next evaporation,
and the code continues on.
Agents cannot do more than one thing at once, so the queued
evaporation cannot possibly happen while this evaporation
I was looking at the same code today. My question is slightly
different. In the code
(defn evaporation [x]
(when running
(send-off *agent* #'evaporation))
(evaporate)
(. Thread (sleep evap-sleep-ms))
nil)
it looks like the next request (when running (send-off...)) is sent
immediately
And 2 is yes, just to stop them at the repl by flipping a flag. Was
especially useful when first coding it up.
Rich
On Oct 29, 11:20 am, Stuart Halloway <[EMAIL PROTECTED]>
wrote:
> Hi Konrad,
>
> I can answer 1 and 3:
>
> (1) *agent* is set thread locally whenever a thread is an agent
> action.
Hi Konrad,
I can answer 1 and 3:
(1) *agent* is set thread locally whenever a thread is an agent
action. It's all in the Java code, grep for AGENT
(3) send uses a thread pool that you should not assume you control, so
blocking for e.g. I/O would be bad behavior and could hurt other
agents
10 matches
Mail list logo
