Oh, sure; absolutely!
So say we have
(get "/other-endpoint" #:mime #t
(lambda (rc)
(:mime rc '(("this is a " . "the other endpoint!")))))
and we also have (using curl since http-get causes things to freeze, for right now):
(get "/test-endpoint" #:mime #t
(lambda (rc)
(display "Something here")
(newline)
(system "curl http://127.0.0.1:3000/other-endpoint")
(:mime rc '(("this is the " . "first endpoint we call")))))
So, if we don't put (break-task) before the system call, the logs show something like
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:16:33 --:--:-- 0
as curl tries to call the local endpoint but, as we know, it'll never load that endpoint until test-endpoint finishes so it just stays at 0% and both endpoint remain frozen, unprogressing.
If we do put a (break-task) before the system call, the logs will print out "Enter ragnarok scheduler!" when it hits the curl call but then thing pretty much never keep going. The logs pretty much end there, other-endpoint never actually ends up getting called and test-endpoint never finishes running and just hangs forever.
But, if we do
(get "/test-endpoint" #:mime #t
(lambda (rc)
(display "Something here")
(newline)
(break-task)
(sleep 20)
(:mime rc '(("this is the " . "first endpoint we call")))))
we can call/hit other-endpoint manually as many times as we want in that 20 second period and it'll load each time and test-endpoint will, eventually, finish and return back the JSON object.
Does that make more sense? Not sure if it's feasible but, heh, that's why I'm asking.
Jonathan