Let's say that I call MailboxProcessor.PostAndReply, which may run for a very long time due to whatever reasons. What would happen if I call MailboxProcessor.Post from some other thread while the first call has not returned yet?
What I mean is, yeah, sure, I can write a test that would recreate this situation. However, before I start reinventing the bicycle, I wonder if anyone already knows the answer on this question.
Thanks a lot!
The short answer: no, it doesn't block.
The longer version:
Mailbox processor uses a regular Queue<T> instead of a ConcurrentQueue<T> - which means posting uses a lock to enqueue, meaning that if a post were to be called from two different threads, one would block the thread till the other call returned - which would happen very fast, but block.
tl;dr: Post does not block is so far as no actual work is done on posting.
Related
First time learning about concurrency and threading within Rails, so any advice is very appreciated.
I currently have an array of 50 strings. I have an 3rd party API call that takes in the string and returns a numeric value. Right now I am simply calling the API on each string one at a time, which takes a really long time.
After looking at a few SO like this one, this other one and finally this one, it seems like I have to use some sort of threading to achieve what I want to do. My plan is to break down the array into batches of ten strings, and then run 5 API calls on each array of ten strings concurrently in hopes that it will drastically reduce the time.
I've never done threading of any kind with rails before, so I just wondering if I am on the right track following the third SO post above, or if I should use other techniques that may be better for my need.
The approach you take will depend on your use case. Do you need to wait for all the calls to be made to do something with the result? Can it be asynchronous?
If you are looking into threads to distribute the work then the third SO post you mentioned is a good way to do it.
If your use case permits the process to be async, I'd definitely look into a scheduler, as mentioned in the first SO post. I've use DelayedJob for this goal, there are some other alternatives.
On a related topic, I usually implement a micro-service that receives those requests and processes them async instead of having DelayedJob in the same app, but is just a matter of preference.
Something REALLY important to have in mind if you go with the async approach is that if you are accessing ActiveRecord records inside a thread you need to explicitly check out the database connection. Rails only handles the check in/out of connections in the main thread. Be really careful on this since it can cause connection leaks really hard to track.
The first answer on this SO post shows how to ensure the db connection to be released.
Hope that helps.
While implementing the callback functionality I bumped into the following problems.
What is a good way to deal with the situation when an ill-behaving callee doesn't return? How can I detect this situation and continue my regular program flow?
My only idea until now is to create a thread which does the actual callback and kill it (and the application) after some timeout.
The second point is that i don't want to give the callee the possibility to mess around with my stack. How can I provide a clean stack for the callee and that with keeping in mind that eventually several callbacks could happen at the same time?
My solution until now is the following approach. Every time when an application installs a callback procedure it has to allocate some memory for stack usage and provide a pointer to it.
I will appreciate your constructive comments and proposals.
It depends on your security model. If your callee is trusted, you needn't to worry. Otherwise, I suggest putting it into a separate process.
You can queue further callbacks until the callback function returns.
Here is a simple question.
suppose that I have a very long loop to execute, It would be nice to keep the user informed about the progressing right? I would print for example the number of loops that have been executed so far and how many are remaining.
The problem that I have is those output wouldn't be visualized until the the loop is finished, and thus there will be no point for them to be displayed.
I'm sure that there is some method in dart that can some sort of a handler to the browser to execute tasks and events whenever I want to and keep running the loop.
I'm new to dart, I hope that someone could answer this question.
Thank you.
PS: If you don't know how to, you can give me any ideas of keywords that I can use to look for this particular feature in dart documentation, it will be very helpful.
You can dig into Isolates, which allow background work on supported browsers.
https://api.dartlang.org/docs/channels/stable/latest/dart_isolate.html
Nothing as simple as DoEvents(), but all of the pieces are there.
I think too that Isolates are the best approach but wasn't successful using them on the browser a while ago, but there was a bigger refactoring going on lately in Isolates.
Does anyone know of a current client side Isolates example?
The API doc referenced by #kevmoo contains a link to an Isolates article that doesn't exist anymore (maybe must be rewritten due to the mentioned refactoring).
Another approach would be a method that returns after a chunk of work and gets recalled repeated in a loop until it returns for example true for done (false for not yet).
When you call this method using scheduleMicrotask(doChunk) or new Timer(() => doChunk()) other tasks get some air (import 'dart:async';) each time before the method gets actually called.
I am developing a WPF application with C# 4.0 where some user-specific code will
be compiled at runtime and then executed inside an AppDomain. The process might take 10 ms or 5 minutes. The AppDomain will be created by Task.Factory.StartNew(). Works fine.
Now I want to be able to cancel/interrupt the execution. I can press a
Stop button while the codes is executing but how can I cancel the Task? I know:
there is the CancellationToken.IsCancellationRequested property but I cannot
loop through something. This is why I cannot check the value while executing
the (atomic) code. And unloading the AppDomain does not stop the Task.
FYI: I took the Task class because it easy to use. If Thread would be useful: No problem.
Can someone help me? A short code snippet would be nice :).
Thank you.
Aborting a thread or a task is a code smell of a badly designed solution.
If that is your decision, you should consider that every line of code could be the last one to be executed and consider releasing any unmanaged resource, lock, etc that could leave the system in an inconsistent state. In theory we should always be this careful, but in practice this doesn't hold.
If you try with a Thread and the inviting .Abort() method, you should consider that ThreadAbortException is a special exception in terms of try-catch and finally blocks. Additionally, you can't even be sure that the thread is going to be aborted.
In regards of using a Task, AFAIK (I'm not an expert in TPL) I'm afraid you cannot do what you want. You should somehow re-design your logic to consider the cancellation token and cleanly stop your computation.
Does anyone know of any good resources that fully explain how functions and results will fire in an Adobe AIR app where multiple things are happening at once?
As a simple test, I've created a single service that I just keep changing the url of, then issuing a send(). It seems that no matter how many send() calls I put in, all of these get executed before the 'result' eventListener function gets called for the first time.
Is this how it works? i.e. the current function gets fully executed, with the async returns queueing up to be processed after AIR has finished what it's currently doing.
Likewise, if the user does something while all this is going on, I presume their request goes to the back of the queue as well?
All that makes sense, but I'm just wondering if it's documented anywhere.
While I'm on one, is it recommended practice to reuse the same HTTPService in this way, or is it better to create one for each concurrent transaction? Just because it works, doesn't mean it's the right thing to do...
I'm not aware of any documentation that explains this, but I can confirm that code blocks get executed before async calls are made, or at least before their result is being processed. If it didn't work that way, you would for instance not always be able to attach a responder to a token of a service call, because the result might already have been processed.
var token:AsyncToken = myService.someMethod();
token.addResponder(new Responder(resultHandler, faultHandler));
Developers coming from other platforms find this strange as they would expect the assignment of the responder to be too late.
So while I don't have an official explanation about the technical details inside the Flash Player, I can assure that it works this way.
If the user does something while a call is pending, the new request will indeed just be added as a new asynchronous call. Note that we can't realy speak of a queue, as there is no guarantee that the response of the first call comes in before the response of the second call. This depends on how much time the actual requests take.
You can perfectly reuse an HTTPService instance.
PS: Based on this, we were able to build the Operation API in Spring ActionScript. It is basically an API that allows you to execute asynchronous processes in a uniform way, without having to worry about the details of the actual async process.
The following code executes an async process and attaches a handler to it. This is also something that puzzles many developers at first, for reasons similar to the asyncToken situation.
var operation:IOperation = doSomeOperation();
operation.addCompleteListener(aCompleteHandler);
operation.addErrorListener(anErrorHandler);