Sometimes I encounter a deadlock, or something that resembles deadlock. When I debug code in most languages, I'll usually pause the program and inspect the state of all the running threads, to see e.g. what the thread that was SUPPOSED to pick up the phone is doing instead. (E.g. via the Debugger > Frames panel in Android Studio.) In Flutter, however, you don't really use threads, you use Futures, and I haven't found a way to get similar information. I'd like a way to see all living Futures and where they're waiting in the code. (In addition to the location each Isolate is executing, I guess, and the Futures categorized by Isolate.) Is there such a thing? Is such a feature planned? (It should be, IMO.)
Related
In Flutter if I create a Timer, will the supplied callback get executed if the application is in background?
I think documentation is not clear on this or I might have missed it (please supply a link if you find it anywhere).
I just tried doing this with a timer set up to 10 seconds and it works fine.
I assume that is approach is not very reliable and other methods* should be used instead. I think if the app is paused/terminated by operating system to preserve battery or due to low memory, nothing will be executed. But for me this situation could be an ok approach.
* I know there are isolates so I guess I could spawn the timer inside one of these. Downside is that the isolate must be regular function (or static method) so no access to application data in my scenario. Then there are different scheduling packages etc but I'm trying to avoid these for now. I know about background tasks but I'm really looking for an answer on code execution using timers.
I'm getting this super obnoxious output printed out thousands of times slowing down my program:
2021-11-08 12:37:57.183588-0800 (myScheme)[27459:701276] [boringssl] boringssl_metrics_log_metric_block_invoke(144) Failed to log metrics
In StackOverflow, I'm only finding that it is related to an XCode bug and there isn't much that can be done about it. However, I'd like to experiment with alternative pieces of code that might be able to perform whatever task is being run but without triggering this stupid issue.
Is there a way I can set a breakpoint for this so I can study the stack trace which leads to it?
Thanks
A few observations:
This output is a simple logging statement (such as generated by OSLog or Logger) in a framework. You generally cannot control what logging these frameworks do, so don’t worry about it.
In terms of slowing down your app, the logging system is exceptionally efficient, depending upon the level of the individual logging message, so I wager that debugging messages are not slowing down your app (observably). There are different logging levels, i.e., “debug”, “info”, “notice”, “error”, and “fault”, each with its own performance characteristics. See WWDC 2020 Exploring logging in Swift. In particular, “debug” logging messages are highly performant.
The real issue is how to filter your debugger console so your salient logging statements don’t get lost in all the cruft from logging statements from all the frameworks you might be using (such as “boringssl”).
I find that filtering the console is extremely useful. Unfortunately, The Xcode console filter does not offer regex or “negative” filters (i.e., you cannot say “show me everything except boringssl messages”). But you can tell it to show you your particular logging statements.
In particular, you might consider using Logger (or OSLog for older targets), instead of print, for your logging statements:
import os
private let logger = Logger(subsystem: Bundle.main.bundleIdentifier!, category: "AppDelegate") // use whatever category you want; I personally use a separate logger for each compilation unit and make the “category” the name of that unit
And later, in lieu of print, use Logger:
logger.debug(...)
(In older targets, you can use OSLog; the syntax is slightly different, but the idea is the same.)
Anyway, when I then look at my unfiltered log, I’ll see all the cruft, where it is hard to see the messages I care about:
But I can focus on my salient events, in this case by filtering on “[AppDele” for log messages from my AppDelegate:
This logging pattern also allows you to watch iOS logging messages emitted by a device on one’s macOS Console, which is critical when diagnosing issues that only manifest themselves when not attached to a debugger. This is illustrated in that WWDC video.
In short, do not worry about framework logging messages, but just have a workflow that lets you easily focus on the console messages that matter.
What's the difference between Thread, Isolate and a Process in Dart?
As far as I know Dart is a single-threaded language, but it can spawn many isolates which don't share memories with each other and we can do the heavy lifting work on them and return the result without blocking the UI.
But what Process is for, is that a part of an Isolate? Can anyone describe above three in more detail.
And when we do asynchronous programming using Future and let's see we are doing heavy lifting in it, will that block the UI thread in case it is awaited using the await keyword.
A Process is a native OS (Unix, Windows, MacOS) construct, which consists of one or more threads with their own address space and execution environment. In Dart, an application consists of one or more threads, one of which is the main UI thread, while the rest are typically called Isolates.
In contrast to what the previous answer said, All Dart code runs in an isolate.
Actually, your understanding is correct, based on what you said in the comments.
From the docs (emphasis mine):
Within an app, all Dart code runs in an isolate. Each Dart isolate has
a single thread of execution and shares no mutable objects with other
isolates. To communicate with each other, isolates use message
passing. Although Dart’s isolate model is built with underlying
primitives such as processes and threads that the operating system
provides, the Dart VM’s use of these primitives is an implementation
detail that this page doesn’t discuss.
Many Dart apps use only one isolate (the main isolate), but you can
create additional isolates, enabling parallel code execution on
multiple processor cores.
Your question hasn't been answered yet, and it will not be answered easily, because it depends on the language implementation.
Also, your another question: "And when we do asynchronous programming using Future and let's see we are doing heavy lifting in it, will that block the UI thread in case it is awaited using the await keyword."
-> Yes, it will block the UI, unless you use another isolate.
I'm using the Scala plugin, and it sometimes likes to hang and spin a rainbow wheel (Mac wait icon) for a long time. It's very annoying. Is there something like a "Control C" for the current thread? I'd like a way to tell Eclipse to kill the current UI command. This would help when use plugins that are not as polished as the one for Java.
There is no such feature and I would not hold your breath waiting for one. Unlike system processes that exist independent of each other, threads are entangled. Force killing a thread is very likely to corrupt various data structures and leave Eclipse process in a bad state.
Various API techniques exist to allow for cancellation of an operation, but they all rely on the running operation to actively check for cancellation request and safely shutdown. Not much help for dealing with unpolished plugins, since graceful handling of cancellation in all cases tends to be implemented as part of polishing.
Is there a way to implement non-blocking / asynchronous execution (without fork()'ing) in Perl?
I used to be a Python developer for many years... Python has really great 'Twisted' framework that allows to do so (using DEFERREDs. When I ran search to see if there is anything in Perl to do the same, I came across POE framework - which seemed "close" enough to what I was searching for. But... after spending some time reading the documentation and "playing" with the code, I came against "the wall" - which is following limitation (from POE::Session documentation):
Callbacks are not preemptive. As long as one is running, no others will be dispatched. This is known as cooperative multitasking. Each session must cooperate by returning to the central dispatching kernel.
This limitation essentially defeats the purpose of asynchronous/parallel/non-blocking execution - by restricting to only one callback (block of code) executing at any given moment. No other callback can start running while another is already running!
So... is there any way in Perl to implement multi-tasking (parallel, non-blocking, asynchronous execution of code) without fork()'ing - similar to DEFERREDs in Python?
Coro is a mix between POE and threads. From reading its CPAN documentation, I think that IO::Async does real asynchronous execution. threads can be used too - at least Padre IDE successfully uses them.
I'm not very familiar with Twisted or POE, but basic parallel execution is pretty simple with threads. Interpreters are generally not compiled with threading support, so you would need to check for that. The forks package is a drop-in replacement for threading (implements the full API) but using processes seamlessly. Then you can do stuff like this:
my $thread = async {
print "you can pass a block of code as an arg unlike Python :p";
return some_func();
};
my $result = $thread->join();
I've definitely implemented callbacks from an event loop in an async process using forks and I don't see why it wouldn't work with threads.
Twisted also uses cooperative multi-tasking just like POE & Coro.
However it looks like Twisted Deferred does (or can) make use of threads. NB. See this answer from the SO question Twisted: Making code non-blocking
So you would need to go the same route with POE (though using fork is probably preferable).
So one POE solution would be to use: POE::Wheel::Run - portably run blocking code and programs in subprocesses.
For alternatives to POE take a look at AnyEvent and Reflex.
I believe you use select for that kind of thing. More similarly to forking, there's threading.
POE is fine if you want asynchronous processing but using only a single cpu (core) is fine.
For example if the app is I/O limited a single process will be enough most of the time.
No other callback can start running while another is already running!
As far as I can tell - this is the same with all languages (per CPU thread of course; modern web servers usually spawn a least one process or thread per CPU core, so it will look (to users) like stuff it working in parallel, but the long-running callback didn't get interrupted, some other core just did that work).
You can't interrupt an interrupt, unless the interrupted interrupt has been programmed specifically to accommodate it.
Imagine code that takes 1min to run, and a PC with 16 cores - now imagine a million people try to load that page, you can deliver working results to 16 people, and "time out" all the rest, or, you can crash your web server and give no results to anyone. Folks choose not to crash their web server, which is why they never permit callbacks to interrupt other callbacks (not that they could even if they tried - the caller never gets control back to make a new call before the prior one has ended anyhow...)