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
