Re: running functions
Tom Anderson wrote: If you program threads with shared nothing and communication over Queues you are, in effect, using processes. If all you share is read-only memory, similarly, you are doing easy stuff and can get away with it. In all other cases you need to know things like which operations are indivisible and what happens if I read part of this from before an update and the other after the update completes, . Right, but you have exactly the same problem with separate processes - except that with processes, having that richness of interaction is so hard, that you'll probably never do it in the first place! It's not all that hard, but you do have to think about it and really engineer your communications (and SHM segments) ahead of time. Which is a good thing, IMO. Really the only difference between threads and processes is that threads share all your memory. When you consider that OS designers spent a lot of time and effort to implement protected memory, maybe that's not often the right thing. Certainly threads have their place, but I avoid them whenever there's an equally easy multiprocess solution (which is the overwhelming majority of the time, but certainly not always). To diverge from the Python world for a moment, imagine a network server that services each connection with a thread (possibly from a thread pool rather than creating a new one for each connection). And imagine another that uses multiple process. Now suppose there's a bug in some extension that segfaults (for instance, when serving large media files). It's very easy for such a bug to bring down the whole server in the multithreaded server; in the multiprocess server it naturally brings down only the one connection, so the rest of the site continues to run happily. Many other stability and security holes are easy to introduce when you eliminate memory protection. I don't really understand the process are really hard thing, either. It's a 5 line wrapper or so to make it look just like the threads interface if you really want to, and you only have to do that once. You do need to worry about IPC, but that is generally simpler than just mucking about in process-wide memory, especially when it comes to maintenance. But... I've done a fair amount of threads programming, although in java rather than python (and i doubt very much that it's less friendly in python than java!), and i found it really fairly straightforward. Java certainly doesn't have any real support for multiprocess programming. I view the lack of good multiprocess solutions in Java to be one of the few major design flaws therein. Indeed, I view the poor performance of processes on Windows (and the accompanying need to use threads for reasons other than memory sharing) to be the biggest single problem with Windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: running functions
On Thu, 17 Nov 2005, Scott David Daniels wrote: Gorlon the Impossible wrote: I have to agree with you there. Threading is working out great for me so far. The multiprocess thing has just baffled me, but then again I'm learning. Any tips or suggestions offered are appreciated... The reason multiprocess is easier is that you have enforced separation. Multiple processes / threads / whatever that share reads and writes into shared memory are rife with irreproducible bugs and untestable code. Processes must be explicit about their sharing (which is where the bugs occur), so those parts of the code cane be examined carefully. That's a good point. If you program threads with shared nothing and communication over Queues you are, in effect, using processes. If all you share is read-only memory, similarly, you are doing easy stuff and can get away with it. In all other cases you need to know things like which operations are indivisible and what happens if I read part of this from before an update and the other after the update completes, . Right, but you have exactly the same problem with separate processes - except that with processes, having that richness of interaction is so hard, that you'll probably never do it in the first place! tom -- science fiction, old TV shows, sports, food, New York City topography, and golden age hiphop -- http://mail.python.org/mailman/listinfo/python-list
Re: running functions
In article [EMAIL PROTECTED], Gorlon the Impossible [EMAIL PROTECTED] wrote: . . . the fly' so to speak. I checked out the threading module and its working for what I am trying to do at the moment, but I am open to suggestions and eager to learn all I can about other options. Thanks . . . If threading is already working for you, stay with it; it certainly has the technical ability to do all you describe for your eventual goal. Apart from that, just keep reading the standard documentation. You might also consider URL: http://www.unixreview.com/documents/s=7822/ur0303j/ and URL: http://www.unixreview.com/documents/s=7750/uni1041364857773/ (except that the latter is now in its second edition--why hasn't the reviewer addressed this yet!?). -- http://mail.python.org/mailman/listinfo/python-list
running functions
Hello I'm not sure how to phrase this question. I have a Python function that sends MIDI messages to a synth. When I run it, I of course have to wait until it is finished before I can do anything else with Python. Is it possible to run this function and still be able to do other things with Python while it is running? Is that what threading is about? -- http://mail.python.org/mailman/listinfo/python-list
Re: running functions
On 2005-11-16, Gorlon the Impossible [EMAIL PROTECTED] wrote: I'm not sure how to phrase this question. I have a Python function that sends MIDI messages to a synth. When I run it, I of course have to wait until it is finished before I can do anything else with Python. Is it possible to run this function and still be able to do other things with Python while it is running? Yes. Is that what threading is about? Exactly. Take a look at the treading module: http://www.python.org/doc/current/lib/module-threading.html -- Grant Edwards grante Yow! BRILL CREAM is at CREAM O' WHEAT in another visi.comDIMENSION... -- http://mail.python.org/mailman/listinfo/python-list
Re: running functions
Gorlon the Impossible [EMAIL PROTECTED] wrote: I'm not sure how to phrase this question. I have a Python function that sends MIDI messages to a synth. When I run it, I of course have to wait until it is finished before I can do anything else with Python. Is it possible to run this function and still be able to do other things with Python while it is running? Is that what threading is about? Threads are a complex answer. Subprocesses are a less complex answer. (good sigmonster, have a biscuit) -- \ I have yet to see any problem, however complicated, which, | `\ when you looked at it in the right way, did not become still | _o__) more complicated. -- Paul Anderson | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: running functions
Gorlon the Impossible wrote: Hello I'm not sure how to phrase this question. I have a Python function that sends MIDI messages to a synth. When I run it, I of course have to wait until it is finished before I can do anything else with Python. Is it possible to run this function and still be able to do other things with Python while it is running? Is that what threading is about? Threading's a good answer if you really need to share all your memory. A multiprocess solution is probably preferrable, though it depends on the architecture. It may be possible to do it in a single process (if, say, the MIDI synth supports waitForMultipleObjects, select, async I/O, or an equivalent thereof) without blocking. -- http://mail.python.org/mailman/listinfo/python-list
Re: running functions
In article [EMAIL PROTECTED], Grant Edwards [EMAIL PROTECTED] wrote: On 2005-11-16, Gorlon the Impossible [EMAIL PROTECTED] wrote: I'm not sure how to phrase this question. I have a Python function that sends MIDI messages to a synth. When I run it, I of course have to wait until it is finished before I can do anything else with Python. Is it possible to run this function and still be able to do other things with Python while it is running? Yes. Is that what threading is about? Exactly. Take a look at the treading module: http://www.python.org/doc/current/lib/module-threading.html . . . I don't agree, Grant (although I salute the brevity of your follow-up), and a couple of other correspon- dents have already posted follow-ups that begin to explore the alternatives. If I were pursuing this, the first question I'd have for Gorlon is whether he's OK with a fire and for- get model. By that, I mean to ask if it's OK to send the MIDI message, and then return immediately to other Python work, OR whether Gorlon also needs to stay in contact with the MIDI handler, and perhaps react especially when the MIDI handler finishes with the specific message. That choice is crucial in a good concurrency design. So, Gorlon, yes, threading is a prominent member of the family of facilities that address situations like yours. It's not the only one, though. -- http://mail.python.org/mailman/listinfo/python-list
