ok, we are getting closer! ^__^
Thanks for clearing it out - I get it now. It is still disappointing that
> the only way to do that is by "polling"... It's not solving the problem,
> just moving it around. It's fundamentally (in terms of execution-model),
> not different than using "long-polling" in the client instead of SSE... In
> both cases you got this scenario:
>
Polling has to be done if your backend doesn't notify you that there is a
new message.
Between a long-polling ajax and SSE stands all the difference
(traffic-wise) that is added by a new http connection: dns resolving,
socket opening, proxies, headers (client-side) and permission checking,
session inspecting, validation (server-side).
The point is not short-circuting the execution model, but short-circuiting
the need to establish a new connection.
That being said, if you choose a backend that notifies you when a new
message arrives, you can also short-circuit the "polling part".
> The whole point of SSE is to avoid that execution model...
> You alluded to Redi's "push" mechanism - I've read your link on Redis's
> Pub/Sub protocol, but couldn't find how the push is being done.
>
The pubsub pattern basically does:
- publish a new message
- all the subscribers receive that message
on redis, the publish part is a method that returns as soon as you sent
that message
publish(channel, message)
the subscribe part is a method that listens "blocking" and "resumes" as
soon as a message is received (so, it blocks if there are no new messages
until there is a new one)
so, in your SSE action you should do something like (pseudo-code)
a = pubsub.subscribe(channel)
while True:
yield a.listen()
> I'm currently looking into the Python-client implementation options there,
> but let's assume that there is a way to listen from Python to Redis - where
> do I put that? Inside the while-loop?
> And how does this "generator-instance-yield in a return statement" work
> from an execution-model perspective? What happens when it's sleeping? Isn't
> the python-run-time blocked? I mean, the controller-action "itself" is NOT
> a generator - it "returns" a generator-instance. It is returning an object.
> That object has a ".next()" method.. Great. Now what happens? Is web2py
> recognizing it as a generator-instance by it's type/methods ? Then it does
> a ".next()" call and issues the result within a response with the response
> headers? What happens then? It sleeps, right? What happens during that
> sleep? And after it finishes sleeping, it does not yield another values by
> itself - a generator is not a self-activating-agency - it needs to be
> called explicitly - only then will it replay the loop and yield another
> result.
>
In a gevent environment the coroutine "context switching" happens when you
put that thread to sleep. This is done in several standard libs where an IO
is done. Additionally, if you monkey_patched web2py (as anyserver.py does),
every sleep() call effectively calls gevent.sleep() that is
"coroutine-friendly": while that coroutine sleeps the execution of other
coroutines can go forward, so yes, a sleep() blocks the execution, but only
of that greenlet, letting other greenlets to pick up from where they were
put to sleep.
As per wsgi specs if the body is an iterator the body is returned in a
chunked-like manner to the client: this enables the yielding loop to
"stream" pieces of information while keeping the connection open.
You can yield with the default threaded webserver, but the way it's
implemented is a pool of threads, that has a maximum vale: as soon as there
are n connections = n of threads of the webserver replying to a connection,
no other connection can be established.
On gevent, on the other end, a new greenlet is spawned at every request and
given that they are lighter, there's (virtually) no upper bound: that's why
an evented environment is recommended (not required, but
"highly-appreciated" nonetheless) while doing long-standing connections.
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
