I'm trying to use a coroutine function outside of the event loop. (In this case, I want to call a function in Django that could also be used inside the event loop too)
There doesn't seem to be a way to do this without making the calling function a coroutine.
I realize that Django is built to be blocking and a therefore incompatible with asyncio. Though I think that this question might help people who are making the transition or using legacy code.
For that matter, it might help to understand async programming and why it doesn't work with blocking code.
After a lot of research I think these solutions could be helpful:
Update your legacy code to use asyncio:
Yes i know that it can be hard and painful, but it might be the sanest choice. If you are wanting to use Django like I was... Well, you've got a lot of work to do to make Django async'd. I'm not sure it is possible, but I found at least one attempt: https://github.com/aaugustin/django-c10k-demo (Though, in a youtube video the author explained all the shortcomings of this).
use asyncio.async or asyncio.Task:
These items will enable you to run something async inside of blocking code, but the downfall here is that you will not be able to wait for them to finish without doing something ugly like a while loop that checks if the future has completed... ugh, but if you don't need the result, that might work for you.
About case #2: Blocking code should be at least wrapped with .run_in_executor.
Related
I'm using an API that has a 'bind' function that I call at the start of my program, but to be a good API user, I need to call the 'unbind' function when my program quits for any reason. Is there a way to do that? I can't find anything on Google, and defer api.Unbind() doesn't seem to get called. Thx.
There is no single way to get a 100% guarantee that some code is called before abnormal program termination. The closest you can get is to react to os.Interrupt (and also syscall.SIGTERM on Unix systems) and make sure your cleanup is done thereafter. A good way to achieve this is to use NotifyContext because it ties in nicely with the context package the main use of which is to allow for implementing cancellation of (potentially) long-running code.
I am trying to understand why we need callbackFlow builder, it seems almost same with channelFlow except callbackFlow is inline. What is the use case ?
They do exactly the same thing. One of them literally calls the other. The difference is in the intention. It is supposed to make your code more self documenting about your intentions.
Use callback flow for callbacks and channelFlow for concurrent flow emission.
EDIT:
As of Version 1.3.4, callbackFlow will detect missing calls to awaitClose, making it less error prone.
So they are now different.
Hi Golang programmers,
First of all I apologize if my question is not very clear initially but I'm trying to understand the proper usage pattern when writing Golang code that uses Goroutines when using the standard lib or other libraries.
Let me elaborate: Suppose I import some package that I didn't have a hand in writing that I want to utilize. Let's say this package does a simple http get request somehow to a website such as Flickr for example. If I want a concurrent request, I can just prefix the function call with the go keyword. But how do I know, that this package when doing the request doesn't already do some internal go calls itself therefore making my go calls redundant?
Do Golang packages typically say in the documentation that their method is "greened"? Or perhaps they provide two versions of a method, one that is green and one that is straight synchronous?
In my quest to understand Go idioms and usage patterns I feel like when using even packages in the standard lib that I can't be sure if my go commands are necessary. I suppose I can profile the calls, or write test code but that feels odd to have to figure out if a func is already "green".
I suppose another possibility is that it's up to me to study the source code of whatever I'm using and understand how it should be used and if the go keyword is necessary.
If anybody can shed some light on this or point me to the right documentation or even a Golang screen-cast I'd much appreciate it. I think Rob Pike briefly mentions in one talk that a good client api written go is just written in a typical synchronous manner and it's up to the caller of that api to have the choice of making it green or not.
Thanks for your time,
-Ralph
If a function / method returns some value(s), or have a side effect like that (io.Reader.Read) - then it's necessarily a synchronous thing. Unless documented otherwise, no safety for concurrent use by multiple goroutines should be assumed.
If it accepts a closure (callback) or a channel or if it returns a channel - then it is often an asynchronous thing. If that's the case, it's normally either obvious or explicitly documented. Asynchronous stuff like this is usually safe for concurrent use by multiple goroutines.
I would like to know how I could run the following loop in a way where it doesn't freeze the GUI, as the loop can take minutes to complete. Thank you.
For i = 0 To imageCount
'code
Next
The short answer is you run the loop on another thread. The long answer is a whole book and a couple of semesters at university, because it entails resource access conflicts and various ways of addressing them such as locking and queueing.
Since you appear to be using VB.NET I suggest you use the latest version of the .NET framework and take advantage of Async and Await, which you can learn about from MSDN.
These keywords implement a very sophisticated canned solution that will allow you to achieve your goals in blissful ignorance of the nightmare behind them :)
Why experienced parallel coders would bother with async/await
Standout features of async/await are
automatic temporary marshalling back to the UI thread as required
scope of exception handlers (try/catch/finally) can span both setup and callback code
you write what is conceptually linear code with blocking calls on the UI thread, but because you declare calls that block using "await", the compiler rewrites your code as a state machine makes the preceding points true
Linear code with blocking calls is easy to write and easy to read. So it's much better from a maintenance perspective. But it provides an atrocious UX. Async/await means you can have it both ways.
All this is built on TPL; in a quite real sense it's nothing more than a compiler supported design pattern for TPL, which is why methods tagged as async are required to return a Task<>. There's so much to love about this, and no technical downside that I've seen.
My only concern is that it's all too good, so a whole generation will have no idea how tall the giants on whose shoulders they perch, just as most modern programmers have only dim awareness of the mechanics of stack frames in call stacks (the magic behind local variables).
You can run the loop on a separate thread. Read about using BackgroundWorker here http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
Is there a use case for recursive locks? Is there a scenario that absolutely requires recursive locking.
Seems to be complicated and dangerous to use. I can see that we may avoid deadlocks (provided the lock stack doesn't overflow) but don't we want to catch such problems.
Maybe I'm missing something here. Any pointers are appreciated.
Thanks in advance.
I like the title of this Blog entry:
Recursive locks will kill you
I also like this quote:
http://www.thinkingparallel.com/2006/09/27/recursive-locks-a-blessing-or-a-curse/
Don’t use recursive mutexes. It’s akin to sex with used condoms.
Finally, here's an extremely interesting article about how recursive locks got into Posix pthreads in the first place:
http://groups.google.com/group/comp.programming.threads/msg/d835f2f6ef8aed99?hl=en&pli=1
Recursive mutexes are a hack. There's nothing wrong with using them,
but they're a crutch. Got a broken leg or library? Fine, use the
crutch. But at least be aware that you're using a crutch, and why; and
once in a while check out the leg (or library) to be sure you still
need the crutch. And if it's not healing up, go see a doctor, because
that's just not OK. When you have no choice, there's no shame in using
a crutch... but you can't run very well on a crutch, and you'll also
be slowing down anyone who depends on you.
Recursive mutexes can be a great tool for prototyping thread support
in an existing library, exactly because it lets you defer the hard
part: the call path and data dependency analysis of the library. But
for that same reason, always remember that you're not DONE until
they're all gone, so you can produce a library you're proud of, that
won't unnecessarily contrain the concurrency of the entire
application.