Hi Alex, thanks for that clarification. "In fact, it has. 'wait' always first checks for pending events before it goes to sleep."
Why does it do that? 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. "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. "where I don't know what '*RedisOnSubRes' contains" It contains: (println (last *RedisSubRes)) I would be fine if I didn't need a loop at the end that needs to wait a certain amount of time, the loop is needed to ping the client to check that it is alive (it will respond with pong if it is): https://bitbucket.org/hsarvell/pl-web/src/default/pl-web.l?at=default&fileviewer=file-view-default (line 368). On Sun, Jan 3, 2016 at 9:45 AM, Alexander Burger <[email protected]> wrote: > Hi Henrik, > > On Sat, Jan 02, 2016 at 10:34:25PM +0100, Henrik Sarvell wrote: >> I've recently implemented pub / sub ( http://redis.io/topics/pubsub ) >> in my redis class ( >> https://bitbucket.org/hsarvell/ext/src/default/redis.l?fileviewer=file-view-default >> ). > > Cool! > > >> (subscribe> R "foo") >> #(wait 1) >> (println "finished") >> >> with ./pil subscribe.l in /opt/picolisp you will see "finished". >> >> If you uncomment the wait line you will not see "finished", the script >> stops on (wait 1) and I have no idea why. >> >> Since I don't pass in a second argument I would assume that wait has >> nothing to do with the *Run global in this case and that execution >> will simply pause for one millisecond and then continue but this does >> not happen. > > In fact, it has. 'wait' always first checks for pending events before it > goes to sleep. In 'subscribe>' you start a task on the socket. If there > are data available on that socket already, that task will be executed. I > can't reproduce your setup, but the task calls > > (run *RedisOnSubRes) > > where I don't know what '*RedisOnSubRes' contains, but I recommend you > trace that one to see where it hangs. > > >> So execution continues as soon as we get something back on the socket >> we have established. > > Yes, exactly. > > >> I don't get why wait literally needs something coming into (in ... ) >> in order to allow continued execution in this case. > > If nothing would be coming in, 'wait' would indeed sleep just for > a millisecond and then return. So it must be the scenario described > above. > > ♪♫ Alex > -- > UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
