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 <hsarv...@gmail.com> 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 <a...@software-lab.de> 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:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to