AFAIK actix_web::web::Payload::next() isn't cancel safe. But I need to read it within tokio::select!. How can I avoid losing messages?
Related
Why and when should we prefer read/writeFileSync to the asynchronous ones on Nodejs in particular for server applications?
For them are blocking functions, you should ever prefer the async versions in production environments.
Anyway, it could make sense to use them during the bootstrap of your application, as an example if you use to load configurations from files and you don't want either to let your fully initialized components to interact with partially initialized ones or design them to be able to work with each other in such a case.
I cannot see any other meaningful use for them.
I prefer to use writeFileSync or readFileSync if it does not make any sense for the program to continue in the event of a failure and there is no other asynchronous work to do. Typically this is at the beginning/end of a program, but I have also used them while "checkpointing" a long running process to make it clear that nothing is changing while the checkpoint is being written to disk.
Of course you can implement this with the asynchronous versions too, it is just more verbose and prone to mistakes.
short question.
I'm using redis-py to set some keys on my redis server and I'm experiencing some weird behaviour.
I suspect it has something to do with the StrictRedis.pipe.
I have multiple threads pushing commands to the same pipe and after a while I run execute on this pipe and run all of its commands.
I wanted to know if the pipe is thread-safe? can I push commands from multiple threads without any synchronisation mechanism?
Thank you.
Looks like it is not, according to the documentation:
"It is not safe to pass PubSub or Pipeline objects between threads."
Therefore I assume you either need some sort of synchronisation mechanism. I have to admit I haven't tested any, but if I were to implement one I would try to go with a Multithreaded queue.
There may be a better way to do it, as I am not a python expert.
Hope this helps, though
Under Redis's SCAN documentation, it mentions this about SMEMBERS:
However while blocking commands like SMEMBERS are able to provide all the elements that are part of a Set in a given moment, The SCAN family of commands only offer limited guarantees about the returned elements since the collection that we incrementally iterate can change during the iteration process.
Surprisingly, I can't find any additional information about how SMEMBERS is blocking and when to avoid using it. If SMEMBERS is a blocking call, is it safe to use in node_redis or will blocking Redis end up blocking Node's thread as well?
Slightly related, if SSCAN is the best practice instead of calling SMEMBERS, is there an equivalent SCAN call for SINTER?
Thanks in advance
Almost all of Redis' commands are blocking, SCAN included (it guarantees short execution time however). The only commands that are non-blocking are those performed by other threads (currently persistence-related only, e.g. BGSAVE).
Specifically, SMEMBERS is blocking. This can be ok if your Set isn't too large (a few K's perhaps(. If the Set becomes too large, Redis will block while preparing the reply and will consume a RAM to buffer it before sending it back. In such cases, iterating through the Set with SSCAN is advisable to allow other requests interleave between calls to it.
I'm using lua as the scripting language for handling events in my application, and I don't want to restrict users to writing short handlers - e.g. someone might want to have one handler run an infinite loop, and another handler would interrupt the first one. Obviously, lua doesn't directly support such behavior, so I'm looking for workarounds.
First of all, I'd like to avoid modifying the engine. Is it possible to set up a debug hook that would yield once the state has reached its quota? Judging by the documentation, it shouldn't be hard at all, but I don't know if there are any caveats to this.
And second, can I use lua_close to terminate a thread as I would in actual multithreading?
I've done something similar in the past. Its completely possible to multi-thread on separate Lua states. Be sure to take a look at luaL_lock() and luaL_unlock() (plus associated setup/cleanup), as you will no doubt need this setup (a simple mutex should do the trick).
After that, it should be a fairly simple matter of creating a lock/wait/interrupt API for your handlers.
I'm using Node and Redis.
If I issue a redis.set() command, is there any chance that whilst that is being set, another read can occur with the old value?
No, you will never have that problem. One of the basic virtues of Redis is that it has a tight event loop which executes the commands, so they are naturally atomic.
This page has more on the topic (see subheading "Atomicity"), and about Redis in general.
Assuming you're talking about two truly concurrent accesses, one write and one read, there is essentially no meaning to this question. If a write is itself atomic and the value is never seen as anything other than the old or new value, then a reader who reads at "about the same time" as a writer may legitimately see either the old or the new value.