I have an Activity A which has a task that needs to be performed in background. So i'm sending the task to async. What happens to activity life cycle when the
myAsyncTask.cancel(true)
is called i.e async task is killed.
According to Android Developers to stop AsyncTask,
A task can be cancelled at any time by invoking cancel(boolean). Invoking this method will cause subsequent calls to isCancelled() to return true. After invoking this method, onCancelled(Object), instead of onPostExecute(Object) will be invoked after doInBackground(Object[]) returns. To ensure that a task is cancelled as quickly as possible, you should always check the return value of isCancelled() periodically from doInBackground(Object[]), if possible (inside a loop for instance.)
and for "what will happen to life cycle of calling activity" i dont know much, you can see here for life cycle of an activity, but as the async task is performed in background the activity will continue to work, but after stopping the asynctask according to documentation found in android studio
The default implementation simply invokes onCancelled() and ignores the result. If you write your own implementation, do not call super.onCancelled(result).
you can do your own implemetation of how to handle after stoping from async task, and after this may be the activity life cycle will be resumed and work normally.
I am not confirmed about this, but let me know if i am wrong somewhere.
Related
I'm curious about this statement:
await Task.CompletedTask;
I know that it nominally doesn't do anything practical, but what I'm wondering is whether it actually causes the running function to exit, then resume at the statement after the await, or whether it truly does nothing and doesn't interrupt the thread at all.
This might make a difference in the sense that it would cause the current run loop to complete and resume, and if the run loop is the main thread it would mean that UI changes got committed.
The documentation doesn't explain it, and I can't figure out a good way to decide which it is.
Thanks,
Frank
whether it actually causes the running function to exit, then resume at the statement after the await, or whether it truly does nothing and doesn't interrupt the thread at all.
await will first test its awaitable to see if it is already complete, and if it is, it will continue executing synchronously.
If you want to force an asynchronous function to yield, then use await Task.Yield();. Side note: this should be extremely rare in production code, but it's sometimes useful for unit tests.
I am a beginner in SAP ABAP. I am debugging an asynchronous RFC (parallel processing). I have put a break-point in the calling portion of the RFC, an external break-point inside the RFC and an external break point in the form which is called at the end of task through perform. I am able to debug the RFC FM.
Another session opens up. But I am not able to debug the perform which is called after end of task. After the RFC is debugged, the control returns to the calling point of the FM. it doesn't go inside the form. When all the iterations are finished, then at the end it goes inside the perform. Why so? shouldn't the perform be executed in parallel?
Inside the perform I have written like RECEIVE RESULTS FROM FUNCTION XXX. But the debugger control is not going inside the perform after returning from the RFC.
You have given very little information on the overall program flow, but there's a part of the documentation that might be relevant to your case:
A prerequisite for the execution of a registered callback routine is
that the calling program still exists in its internal session when
the remote function is terminated. It is then executed here at the
next change of the work process in a roll-in. If the program was
terminated or is located on the stack as part of a call sequence, the
callback routine is not executed.
[...]
The time when the callback routines are executed can be programmed
explicitly or be reached implicitly:
The statement WAIT FOR ASYNCHRONOUS TASKS is used for explicit programming. As specified by a condition, this statement changes the
work process and hence executes the callback routines registered up to
this time. It waits for as many registered routines to end until the
condition is met (the maximum wait time can be restricted). Explicit
programming is recommended whenever the results of the remote function
are required in the current program.
If the results of the remote function are not required in the current program, the time at which the callback routines are executed
can also be determined by an implicit change of the work process (for
example, at the end of a dialog step). This can be a good idea, for
example, in GUI scenarios in which uses of WAIT are not wanted. In
this case, it must be ensured that the work process changes before the
program is ended. There is also a risk that, if the work process is
changed implicitly, not all callback routines are registered in time.
It is likely that the program issuing the call and registering the callback routine is either terminated or does not issue a WAIT FOR ASYNCHRONOUS TASKS so that the callback is only executed on the next roll-in.
Re-reading your question, you apparently assume that the callback routine will be executed in parallel to the program that has registered it. That is not the case, ABAP is not multi-threaded.
I have a queue like the following in laravel,
Mail::queue($notificationCreated->template, $data, function ($message) use ($data) {
$message->to($data['email'], $data['first_name'])->subject($data['subject']);
});
Is it possible to execute a task after queue completes it's execution, i.e in my case after sending a mail.
Something like this is not present in the API because that's not the point of Queue.
It's asynchronous so after calling Mail::queue you immediately get back control and code execution continues. That does not mean the actual job has been executed, just that it's been scheduled.
And there's no way of writing a Mail::whenJobIsComplete there because that would mean the whole execution of your code would have to stop and wait for the job to be completed. There no way this could work asynchronously.
You could however periodically poll for completed jobs and execute code when that happens. There's build-in functionality for polling for failed jobs in the API.
But the best approach would be to write your own custom queue listener,
and adding functionality besides the handleWorkerOutput call.
Again, this is asynchronous, this code will run at some indeterminate point in the future, not even close to the place where you initially called Mail::queue.
Another newbie question:
In the following code, what if the thread is preempted after calling 'set_current_state' but before 'schedule' is called. When the code is scheduled again, does it start from 'schedule' call and is removed from the run queue? Or the 'schedule' call is ignored this time and starts from the set_current_state(TASK_RUNNING) statement?
{
...
set_current_state(TASK_INTERRUPTIBLE); /* suppose thread is preempted just after this function call */
schedule();
set_current_state(TASK_RUNNING);
...
}
Here's (more or less) what will happen if involuntary preemption happens after the first line and before the second:
The scheduler will run (scheduler() function from sched.c) - since this is what being preempted mean.
Since your task is marked as not runnable, the scheduler will remove it from the run queue and will pick another task.
Now your task will not be scheduled until something external will mark it as runnable again. This might happen due to a signal sent to the task or, assuming the task is queued in a wait queue, due to the event the wake queue belongs to happening, but something external MUST mark the task as runnable again or it will never be scheduled. This is why if you look at the wait queue code, it first put the task on the wait queue and only then does something similar to your code.
When your task is marked as runnable, at some point the scheduler will pick it and will context switch into the task code.
Then the schedule() function will get called. In all likelihood, the scheduler is going to pick the same task yet again, since it has just been picked by it as most eligible for running and it is not likely that this have changed.
On the way back from the scheduler, the last set_current_state will basically be a no op, since the task by this time is already marked as runnable in this scenario.
I have been doing some web application programming using GWT and have been confused by the term "browser event loop".
I have encountered situations where I need to execute deferred commands and "do something" after the browser event loop completes.
I would like to know as to what exactly it is and what happens during the event loop process and in which order?
A browser event loop is a thread started by the browser that is constantly scanning for and running different events, just like it sounds. As events occur they are put in the event queue and run in turn by the one event thread. Your javascript should not create its own loops waiting for it to complete or anything like that...it will block that one continuous event loop thread. Instead you would use something like setTimeout or setInterval and check for whatever conditions you are waiting for so the browser can do work while it 'waits'.
GWT is nice in that it can co-opt this process somewhat using the scheduler -- in your case where you want to run something after the event loop 'completes' you will probably want to use scheduleFinally or scheduleDeferred. It will inject a handler for a piece of code into the event queue so that it will run after all other code in the current execution context (current execution context == where ever you are in the current JavaScript object hierarchy with the window as the root object) is run but before the next event that is placed in the queue.