Race Issue
So, I'm writing a program in Python that tries to control other
programs. This is called process
control.
I have process A that kicks off process B. Now, A sends an instruction
to
B. B runs off and tries to get the information like a good little
process. All they really want to do is pleas we programmers. But, A has
already tried to read the answer that B is looking for. So, when B
comes
back with the answer, God bless that little process for trying, A is
just
sitting there and won't take the answer. B will not go do anything else
until A tels it to. A is still trying to get the answer that it missed.
This is called a deadlock. it is some times called a race condition
because A beat B when it should have been the other way around. Adam,
correct me if I'm using the wrong terms.
It turns out this has nothing
to do with Python really. It is an inherent problem with the logic of
computers.
I'm bumping in to one of the fallacies that has plagued
programmers since the beginning of, well, programming. Aristotle and
Plato didn't have to worry about race conditions I bet. This
information doesn't make it any less of a pain in my ass.
. . . (Later in the day I wrote the following on the same subject. I
don't know if I intended it to be in the same post or a separate one,
so here it is as I typed it.)
Python Forking
I called my sweetie and asked her what's up. She replied that she was
at Cole's clothing store with a friend of her's. it is the tax free
weekend you know. I need socks come to think of it. Anyway. She asked
me what I was doing and I responded "I'm forking and my head hurts."She
was a bit lost on the whole concept of forking in programming. And why
shouldn't she be lost. Sometimes I wish I didn't know how these things
work. It makes me nervis when I know how things work. I'm amazed
anything using computers manages to work.
I am trying to get one program to properly control another via Python.
I'm sure you have heard me gripe about this recently. They tried to
make it easier by adding a new module called subprocess. This module
has all kinds of functionality that lets you create a subprocess and
then control it via a method called communicate. The trouble is,
communicate kills the subprocess in the process of reading from
standard out. What the hell good is that? It is fine if I'm firing off
a "uname -a" or something, but I want to interact with the program and
make it do stuff based on decisions I make in the parent process. I
need something more than a one time gather information.
I started digging in subprocess.py and found that they do a fork. I
started digging online and found a person who made it look simple.
The example is not exactly what I need, but it is a start. In order to
get control of standard in and out, you have to use a function called
pud2, and there is fuckall documentation for it. There are some
examples floating around. I basically get the idea of what to do, but
how about some directions for God's sake. I'm apparently in a gray area
for Python.
When you look at the documentation for Subprocess, the first thing they
say is that this new module is supposed to replace like five old ways
of doing the same thing. Generally, this means they still don't have it
quite 100%. I don't have time to wait for Python to get their shit
together. I'm just going to have to write my own process handler that
does what I need. I hope I'm up to the task.
It wasn't me. You can't prove anything.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment