On Sun, Nov 23, 2014 at 11:07 AM, Dave Angel <[email protected]> wrote: > Please don't top-post. Trim the quoted portion to the parts you're > responding to, and put your response immediately after (each) section you're > commenting on. > I this the correct formatting and in plain text?
> Also, you're posting in html. That's not always a problem, but it often is, > depending on the vagaries of your email program. Just tell it you want text > format for your messages here, and we'll all see the same thing. > > On 11/23/2014 10:15 AM, Mitch Raful wrote: >> >> Thanks for the replies. My concern was as the for loop keeps sending >> objects into the do_something() function which uses the same reference >> name >> other_object and that the previously instantiated other_objected would be >> mutated if the function wasn't finished. > > > I can't process that. I don't know what you're asking. > I think you actually answered this one. Since the for loop has to wait for the function to return, my 'other_object' can not get clobbered. >> Or do all languages keep each >> call to a function in its own memory space and there is not a collision?. > > > No such statement for "all languages," as there are tens of thousands of > them, at least. And certainly there are some that support implicit > concurrency via something like "for all" meaning "you may do all of these > in parallel if you like, and I promise that order doesn't matter". > > In Python, however, the function as you had it in the original message > returns to the for loop before it gets called again. So there's only one > instance of the stack frame. > > Three ways there can be multiple stack frames for the same function: > > 1) the function calls itself, directly or indirectly > 2) you have multithreading > 3) you have multiprocessing > > In all of these cases, the name other_object is unambiguously replicated in > each instance of the stack frame. And each version of that can be bound to > an independent object. > >> Since, in my case, do_something() actually occurs over a network and I use >> the logging module, I noticed the responses come in whatever order they >> have completed and not the order that do_something is called. > > > Then you are not just doing a simple function call. You're doing some form > of asynchronous I/O, either by threading, or by non-blocking I/O. In either > case, your original example doesn't begin to represent what you're doing. > Sorry for the newbie mistake of not mentioning that. > The "responses come in" imply that somewhere you're polling for those > responses. Or you've changed your code to use multiple threads (as you show > below). > >> I also have >> another function that downloads the resulting files on the devices that >> do_something() has them generate. To get all of this to look orderly in >> a >> log output, I did this... >> >> for object in objects: >> t0 = Thread( target=do_something, args=(object,)) >> t0.start() >> t1 = Thread( target=get_files, args=(object, backup_dir)) >> t1.start() >> >> As to whether I read this somewhere, I wish I could blame a publication. >> Alas, I came up with 'beauty' on my own. > > > Once you launch a second thread, you have to worry about when it's done > updating the corresponding item in objects. So somewhere you probably want > a wait() call. > Would a t0.join() work instead of a wait call? Mitch > Anyway, the need for threads is triggered by my point 1), a need to continue > your loop without waiting for the first operation to complete. It doesn't > happen to be the user interface that's causing it, but the network. You've > decided that you want to start multiple network operations without waiting > for the first to complete. That's easiest done with threads. > > -- > DaveA _______________________________________________ Tutor maillist - [email protected] To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
