Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Ok, so one can write a custom made eventloop over using given asyncio's eventloop (Writing an EventLoop without using asyncio)
Now the question rises is why? Why prefer writing a custom made over asyncio's eventloop?
Why prefer writing a custom made over asyncio's eventloop?
Usually you invent something new if existing approach doesn't fit your needs. Or may be if you think you can do things more efficiently or conveniently.
First of all it worth noting that asyncio itself provides multiple event loop implementations. Reason for this is that they built on top of different low-level OS API an can behave differently. You can select (or write your own event loop) that fits your task best.
Sometimes people create their own event loop implementations for better performance. Good example of such case is uvloop.
Sometimes people create event loops on top of other non-asyncio event loops. For example quamash provides event loop on top of Qt. It allows to write asynchronous programs using PyQt.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Im running both a uni and multi threaded version of an application. There is no speed advantage. That said, what is the best way to access an Arc<Mutex<Vec>> and process each entry concurrently?
You cannot process an Arc<Mutex<Vec<T>>> concurrently - the mutex wraps the entire vector, so no other thread other than the one that locked it will be able to access it.
If you know the number of elements up front, you can use an Arc<Vec<Mutex<T>>>. This has a mutex per-element, so threads will lock only the elements. However you won't be able to grow or shrink the Vec since its shared.
There are also more specialized structures in the Concurrency section of http://lib.rs, with varying semantics, that may fit your needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want the user to be able to write their own math functions in my program. And these functions could possibly be shared with someone else, and run natively on their machine. Algebra is Turing complete. Does it mean I should warn users of my program about potential danger of running math? Sorry if this is a silly question :)
Edit:
I am making a simple diary, but the entries have dynamically calculated properties. I am thinking of using bc for running the user defined functions. It's rather easy to fix things for user if the expression does not end since they can modify the expression outside of the program. But let's say user A sends user B their diary. Should I warn user B that it's not safe to open their diary?
For example, you can have a Turing-complete language with recursion, but limit the stack size and run time (to kill the busy beavers) for each user script. If it's implemented as some kind of a VM it'll be very easy to do. You can also have a total functional language to ensure termination (but that won't solve the busy beavers problem).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I have two Rust threads; to send a struct from one thread to another I would use a channel. Now I want to split these threads into two OS processes.
Is there a simpler way than using a TCP socket and serializing to JSON back and forth?
I'm fairly new to all of this so I don't even know what terms to Google.
In terms of what to google for the keyword you are looking for is inter-process communication (IPC). There are several ways of doing that and as already mentioned in a comment, Rust doesn't offer much in the standard library.
The thing is that there are many ways to do inter-process communication, each with its own benefits and draw-backs. Maybe start reading here, it will give you some hints on what to google for.
Specifically for your question, if you are concerned about performance when serializing your structs to json you can stick to binary formats as well. Bson might be an option you can have a look at.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm writing a multi-threaded program and all these threads should write their data to a single file.
these threads only writing different strings for some kind of append-only logging
whats the best practice for sharing a file between threads for out put?
For logging (for future questions, make sure you put that information into the question rather than just a comment) there's a strong preference to not have the threads do file access they don't have to; as it means that logging negatively impacts performance for the rest of that thread.
For that reason, NathanOliver's suggestion of having the threads write to a shared container and then one dedicated to dumping that container to file would probably be the best option for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Currently I have n suppliers web service which gives me search result for particular product. I am creating n threads myself and merging the final results returned by supplier. I have just come to know about PLINQ. I want to know if it would help the performance. If yes, how.
Better? Depends on what that means for you. PLINQ is definitely cleaner and more maintainable code for a lot of use cases. On the performance side depends on what you compare it against.
In your case if you are creating n threads by hand i would say you might be slower because PLINQ will use the threadpool and avoid some thread creation overhead.