I think we're in violent agreement. I'm just worried about the difficulties of arranging for the afterHandle calls to occur in a different thread. It's a huge change with lots of potential for hard-to-detect bugs. I'm not arguing against doing it.
--tim On Sun, Dec 25, 2011 at 12:02 AM, Tal Liron <[email protected]>wrote: > I would have two answers: > > 1) Isn't that the price to pay for asynchronicity, and the desire of the > user? The whole point is to implicate a different set of threads into > communication with the client. Of course, hybrid > thread-pool-plus-event-driven servers come to mind, which queue up event > responses but handle them on a single thread pool. There are advantages to > that, but it didn't seem to be the design goal for Restlet. > > 2) It could be handled by the application's TaskService. Still, I would > imagine that the user would not always want that. How about this: > > response.commit(token) > > ...to commit in the current thread, and... > > response.commitLater(token) > > ...to commit in the TaskService. > > > But doesn't that still leave the problem of arranging for all the > > afterHandle calls to happen in the thread that does that commit? That's > > what scares me. > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2899780 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2899884
