On Jul 7, 11:17 am, David Nolen <dnolen.li...@gmail.com> wrote:
> On Wed, Jul 7, 2010 at 2:10 PM, James Reeves <jree...@weavejester.com>wrote:
>
>
>
>
>
> > On 7 July 2010 19:04, David Nolen <dnolen.li...@gmail.com> wrote:
> > > So something like this:
> > > (defn hello-world [request]
> > > (future
> > > (Thread/sleep 1)
> > > (respond! request
> > > {:status 200
> > > :headers {"Content-Type" "text/html"}
> > > :body "Hello world!"})))
> > > Is non-blocking and perfectly fine?
>
> > Actually that rather defeats the point of a non-blocking server.
> > You're still using up a thread, and hence haven't really gained
> > anything over:
>
> > (defn hello-world [request]
> > (Thread/sleep 1)
> > {:status 200
> > :headers {"Content-Type" "text/html"}
> > :body "Hello world!"})
>
> > The main advantage of a non-blocking server is that you're don't use
> > up a thread waiting for an event (such as the user sending data, or
> > some other external trigger).
>
> > - James
>
> But I guess I'm trying to figure out what the most idiomatic way to pipeline
> in this situation would be (one thing I don't like about Node.js is that it
> encourages working with a mess of callbacks).
>
> For example what would be the best most idiomatic way to hit a database
> (blocking operation), process that data and return the result with respond!
> ?
>
> David
I'd say the most idiomatic way to hit a database is to use one that
has a non-blocking interface (postgres is one example). Barring that,
I'd say that the future approach is slightly better than the thread-
per-request model because it uses a thread pool, but otherwise the
chain is only going to be as strong as its weakest link.
--
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
