Turns out you were right, didn't help with call sleep as the task waiting for websocket connections got "blocked" instead.
I worked around it by simply doing a small publish on the same socket immediately after subscribing to get something on the channel. Ugly but works. >From the Redis page above: "The replies to subscription and unsubscription operations are sent in the form of messages, so that the client can just read a coherent stream of messages where the first element indicates the type of message." Seems like I'm doing something wrong because I'm simply not able to get at that initial reply, in fact it looks like it's coming when the first publish happens, which I'm now forcing. On Mon, Jan 4, 2016 at 10:34 AM, Henrik Sarvell <[email protected]> wrote: > Yes, very easy indeed :) > > I actually tried to google for it but I used the wrong search terms. > > On Mon, Jan 4, 2016 at 8:02 AM, Alexander Burger <[email protected]> wrote: >> Hi Henrik, >> >>> "In fact, it has. 'wait' always first checks for pending events before >>> it goes to sleep." >>> >>> Why does it do that? >> >> This is exactly the purpose of 'wait': Wait for events. The milliseconds >> are just a timeout value. >> >> >>> If I had access to a wait that simply stops >>> execution and nothing else everything would be good, I tried to create >>> one of my own but it uses too much CPU in the loop. >> >> Well, that's easy: >> >> (call 'sleep 2) >> >> Also (at least on Linux) this works: >> >> (call 'sleep "0.1") >> >> >>> "If there are data available on that socket already, that task will be >>> executed." >>> >>> It is listening (subscribing) for data so there is no data available >>> to begin with. >> >> But there must be something, otherwise it would not wake up. Try to >> (trace '...) or '$ strace ...' it. >> >> ♪♫ Alex >> -- >> UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
