> 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) > > Yup. That's my point - without gEven, it would be blocking, and thus useless... While it is blocking, we2py is essentially stalled - It's like your main server just got stuck, and is not receiving anything else as of that moment - It will not be able to get out of the loop - ever - until you manually crash it...
> a = pubsub.subscribe(channel) > while True: > yield a.listen() > > 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. > > Yes, I have been learning about gEvent's implementation of sub-routines - it's basically using a c-compiled module that plays with moving things between the stack and the heap of the PVM process. I also know how event-loops are working with python's co-routines (generators). I meant that in the example-application which is supposed to show web2py's capability of using SSE on the server, in a default-deployment, without gEvent, it as mislead me to believe that web2py "by itself" can support SSE on the server, for "real-world" use-cases - and it can't - so I got upset and disappointed. > 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. > That's actually the interesting bit - it is as I suspected - this is good news! :) > > 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. > > Yes, I know. -- --- 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.
