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
