On Dec 15, 7:29 pm, Rich Hickey <richhic...@gmail.com> wrote:
> On Dec 15, 5:57 pm, Bradbev <brad.beveri...@gmail.com> wrote:
>
> > I have the following scenario:
> > - a server that is listening on a socket for incoming connections.
> > - when the server accepts a connection it uses send-off to run a
> > handler function to handle the connection
> > - the handler function loops using recur to handle packets
> > - the handler function uses send-off for some packets so it can
> > render a gui
>
> > I know now that this won't work because when code running in an agent
> > uses send or send-off, those sends are not dispatched until the agent
> > changes state (ie, when the function returns). Because I am looping
> > in my handler, none of its send-offs work.
>
> > Would it be a good rule of thumb to say "agentsshould not use recur,
> > but instead should use send-off to re-schedule themselves"?
>
> For now, yes if they send other actions.
>
> > Is this a performance impact? (ie, recur vs send-off)
>
> Yes.
>
> > Why are sends held until the agent state changes?
>
> Because it is a common and otherwise impossible-to-implement case to
> send actions to others after your state has changed (i.e. your new
> state is the value of your final expression).
>
> >Is it a technical reason, or a conceptual one?
>
> It was done to facilitate the above scenario, but there isn't a
> technical reason to preclude the other. If you look at the todo list:
>
> http://richhickey.backpackit.com/pub/1597914
>
> you'll see an entry for release-pending-sends, the API I'm considering
> for enabling sends prior to state change.
>
release-pending-sends added in svn 1185.
Rich
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
