I am trying to create a task from another task. I tried few sources but am not getting any better results. I tried the example given on https://www.instructables.com/id/FreeRTOS-With-Arduino-08-Creating-a-Task-From-Othe/. In the serial monitor it only displays "In Setup function Task3 Running, Creating Task2 and Task4". With reference to creating task inside other task in freertos
I tried checking the value returned by xTaskCreate and printing the return value but that value doesn't print. Can someone help on this? What is it that I am missing?
I can't help with project specifics, or instructions on other website, but yes it is perfectly fine to create one task from another. That is what the strangely named 'death' tasks demonstrate - one of the oldest (very first) standard demo tasks that shipped with FreeRTOS and runs on all the platforms [we support ourselves].
Related
I'd prefer that Dart not log the current test description every second the test is under execution. If some test takes 5 seconds, Dart is logging the test description 5 times.
I would prefer the logging only represent the one time the test is attempted to be executed.
This is such strange default behavior when compared to other test suites, but I can't find anyone talking about the problem or offering solutions.
Apologies for answering my own question. Reporters (not logging) is the key search term.
There are four reporters available in the default Dart test package. You set the reporter by adding the --reporter <reporter_name> flag on the test command line.
https://github.com/dart-lang/test#selecting-a-test-reporter
The default is "compact" which logs continuously. The one I want to use is called "expanded".
I am using Sidekiq and Rails (6.0.3.7). I have a worker which executes an async task that creates a lot of data on my database, sequentially. So basically what it happens is, for example:
First, it creates an User, then it creates a PostCategory, then it creates a Post, and then it creates 10 comments.
Sometimes, this process fails midway, maybe when creating a PostCategory, or when creating Post.
What i want to happen is that if the task fails at any given point, all the data that has been already created in said task, is discarded. Another approach could be that all the data is created only once i am sure the process has not failed. So basically it would have to "check create" everything, before actually writing to the database.
An example of this would be that the User has been created, but for some reason, it failed to create a PostCategory, and the AsyncTask failed. What i want to happen is that it automatically deletes the created User, or that it was never created in the first place, because the task failed.
Is there any approach or technique i could use to do this on my current worker without messing around too much with the actual code? Some "double check" method already implemented on Sidekiq? What do you recommend i should look into?
Thanks in advance for any help you can give me with this issue.
First of all, great, that you design your tasks to be all-or-none. The main and preferable approach is to use database transactions, as that is what they were designed for. Open transaction before starting entity creation, and commit once all the checks are done.
Account.transaction do
balance.save!
account.save!
end
Note bang methods (those with trailing !) their intent is to throw exceptions. An exception will automatically rollback the transaction, and that's what you need.
N.B. Try to make your task idempotent which mean returning the same result regardless of the number of calls with the same input results. This could save lots of time in the future.
For Elastic Search version 6.0
to cancel a running task:
POST _tasks/node_id:task_id/_cancel
I am following the same statement, but in actual it is unable to cancel the task. After running this command if I run get command to fetch all running task, the particular task don't get cancel.
If I hit cancel statement again, it gives statement that task_id is already cancelled but in reality it doesn't get cancel.
Calling the _tasks/<id>/_cancel endpoint only signifies to ES that the task should be cancelled. ES will then cancel the task as soon as it possibly can.
It might not be immediate, though, for instance, if you have a very complex search that takes a long time (e.g. wildcard queries with leading wildcards).
If you check the ContextIndexSearcher class and look for all places where checkCancelled.run() is called, those are the only phases when a query can be cancelled, but sometimes a phase can take a long time before being eligible for cancellation.
If your task is a search task, then you might try to leverage the timeout parameter to see if it helps (it might not always for the same reasons as mentioned above).
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 use ASP.Net MVC 5 and I have a long running action which have to poll webservices, process data and store them in database.
For that I want to use TPL library to start the task async.
But I wonder how to do 3 things :
I want to report progress of this task. For this I think about SignalR
I want to be able to left the page where I start this task from and be able to report the progression across the website (from a panel on the left but this is ok)
And I want to be able to cancel this task globally (from my panel on the left)
I know quite a few about all of technologies involved. But I'm not sure about the best way to achieve this.
Is someone can help me about the best solution ?
The fact that you want to run long running work while the user can navigate away from the page that initiates the work means that you need to run this work "in the background". It cannot be performed as part of a regular HTTP request because the user might cancel his request at any time by navigating away or closing the browser. In fact this seems to be a key scenario for you.
Background work in ASP.NET is dangerous. You can certainly pull it off but it is not easy to get right. Also, worker processes can exit for many reasons (app pool recycle, deployment, machine reboot, machine failure, Stack Overflow or OOM exception on an unrelated thread). So make sure your long-running work tolerates being aborted mid-way. You can reduce the likelyhood that this happens but never exclude the possibility.
You can make your code safe in the face of arbitrary termination by wrapping all work in a transaction. This of course only works if you don't cause non-transacted side-effects like web-service calls that change state. It is not possible to give a general answer here because achieving safety in the presence of arbitrary termination depends highly on the concrete work to be done.
Here's a possible architecture that I have used in the past:
When a job comes in you write all necessary input data to a database table and report success to the client.
You need a way to start a worker to work on that job. You could start a task immediately for that. You also need a periodic check that looks for unstarted work in case the app exits after having added the work item but before starting a task for it. Have the Windows task scheduler call a secret URL in your app once per minute that does this.
When you start working on a job you mark that job as running so that it is not accidentally picked up a second time. Work on that job, write the results and mark it as done. All in a single transaction. When your process happens to exit mid-way the database will reset all data involved.
Write job progress to a separate table row on a separate connection and separate transaction. The browser can poll the server for progress information. You could also use SignalR but I don't have experience with that and I expect it would be hard to get it to resume progress reporting in the presence of arbitrary termination.
Cancellation would be done by setting a cancel flag in the progress information row. The app needs to poll that flag.
Maybe you can make use of message queueing for job processing but I'm always wary to use it. To process a message in a transacted way you need MSDTC which is unsupported with many high-availability solutions for SQL Server.
You might think that this architecture is not very sophisticated. It makes use of polling for lots of things. Polling is a primitive technique but it works quite well. It is reliable and well-understood. It has a simple concurrency model.
If you can assume that your application never exits at inopportune times the architecture would be much simpler. But this cannot be assumed. You cannot assume that there will be no deployments during work hours and that there will be no bugs leading to crashes.
Even if using http worker is a bad thing to run long task I have made a small example of how to manage it with SignalR :
Inside this example you can :
Start a task
See task progression
Cancel task
It's based on :
twitter bootstrap
knockoutjs
signalR
C# 5.0 async/await with CancelToken and IProgress
You can find the source of this example here :
https://github.com/dragouf/SignalR.Progress