Hi Ivan, Thanks for the tip. I'll get the polling solution working until Java 7 is supported by Clojure. I really want to see how well I can model different network protocols using Clojure's agents as asynchronous state machines, as this is why I started looking at Clojure in the first place.
I have an partial FTP implementation in C++ using I/O completion ports, but I'm fed up of writing state machines in C++/Java/Python. It's such a hassle and Clojure makes this so natural and easy that they're fun to write! Regards, André On Fri, Apr 15, 2011 at 2:22 PM, Ivan Koblik <ivankob...@gmail.com> wrote: > Hello André, > > Just wanted to mention that Java 7 is feature complete. You can see the > list of approved features here: > http://openjdk.java.net/projects/jdk7/features/ > > It seems that JSR203 was selected for the release, although I remember > reading that Clojure won't support Java 7 for awhile. > > Cheers, > Ivan. > > > On 15 April 2011 02:13, André Caron <andre.l.ca...@gmail.com> wrote: > >> After further analysis, I don't think this is globally a good >> strategy. >> >> I looked into a solution with a "(ref (clojure.lang.PersistentQueue/ >> EMPTY))" in the selector agent. The plan was to have be able to queue >> "updates" to the schedule synchronously. Half-way through the >> implementation, I realized this is equivalent to by-passing the entire >> agent system and still wouldn't work anyways. >> >> Even *if* send/send-off were forced to queue synchronously, the wakeup >> strategy isn't guaranteed to work. There is still the possibility >> that "Selector.wakeup()" will be executed after the "dispatch" action >> has started, but before it calls "Selector.select()". What would be >> necessary is for the agent system to sort-of interrupt calls to >> "dispatch" as soon as something else is sent to the agent. Apart from >> requiring the most insane hack ever, this solution would be nothing >> close to elegant. >> >> Basically, I can't block on "Selector.select()", so I have to poll. >> Can't wait for JSR203 (http://www.jcp.org/en/jsr/detail?id=203) to be >> approved as part of Java 7. Maybe that API will be less of a >> hassle... >> >> By the way, this is all for an open source project. I've got the >> basic parts working, but it's still under heavy architectural >> changes. As soon as version "0.1" is decent, I'll push the repository >> to GitHub and notify you guys. >> >> >> Regards, >> >> André Caron >> >> On Apr 14, 5:58 pm, André Caron <andre.l.ca...@gmail.com> wrote: >> > I've posted this question on StackOverflow[1], but it might be a bit >> > technical, so I'll ask it on the mailing list where I might get more >> > precise expertise on Clojure. >> > >> > [1]: >> http://stackoverflow.com/questions/5669084/clojures-send-is-asynchronous >> > >> > I'm writing a simple networking framework for Clojure using Java's >> > "New I/O" package. It manages a pool of "selector agents", each of >> > which holds a `java.nio.channels.Selector`. >> > >> > I defined a `dispatch` action to for the selector agent. This action >> > blocks on a call to `Selector.select()`. When that returns, the >> > selector agent iterates over the selected keys and performs I/O. When >> > I/O is completed, the selector agent send's itself the dispatch action >> > using `send-off`, effectively looping on calls to `Selector.select()`. >> > >> > When I want to add a new channel or change a channel's interest ops, I >> > send the selector agent the appropriate action and then unblock the >> > selector (it's blocked on `Selector.select()`). This ensures that >> > `(send-off selector-agent dispatch)` in the selector agent is executed >> > after `(send selector-agent add-channel channel)` in whatever agent >> > changed the `SelectionKey.inrestOps()`. >> > >> > I thought this would be bullet-proof since the call to `send-off` is >> > performed before the selector waking up, and thus, before the selector >> > agent send itself the `dispatch` action. However, this yields >> > inconsistent behavior. Sometimes, the `dispatch` action occurs first >> > and sometimes it doesn't. My understanding is that `send` and `send- >> > off` are themselves asynchronous in that they return before the agent >> > action being sent is actually queued in the agent's action backlog. >> > >> > Is this correct? >> > >> > This is normally not an issue; the action dispatch from different >> > agents/threads to the same agent is usually unpredictable and a non- >> > issue. In this case, the real culprit is that I need to block on >> > `Selector.select()`. One obvious workaround is to put a timeout on >> > the sleep operation, so that I don't need to manually unblock the >> > selector. This puts me in the classic polling lose/lose situation, >> > where I need to decide on the polling frequency: too few polls and >> > suffer latency, too many polls and slow down the whole machinery. >> > >> > Does anyone have any better ideas, or can `send`/`send-off` be made to >> > actually queue the actions synchronously such that they are executed >> > int the *exact* order they are sent? >> > >> > Thanks, >> > >> > André Caron >> >> -- >> 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 >> Note that posts from new members are moderated - please be patient with >> your first post. >> 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 >> > > -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
