On Sep 11, 2014, at 2:29 PM, Ervin Hegedüs <airw...@gmail.com> wrote:

> Hi Travis,
> 
> On Thu, Sep 11, 2014 at 02:06:48PM -0700, Travis Griggs wrote:
>> 
>> On Sep 11, 2014, at 11:18 AM, Chris “Kwpolska” Warrick <kwpol...@gmail.com> 
>> wrote:
>> 
>>> Depends what you want. 
>> 
>> Mine is not a web service. My main.py looks like this:
>> 
>> #!/usr/bin/env python3
>> 
>> import cycle
>> import pushTelemetry
>> from threading import Thread
>> 
>> def main():
>>    Thread(target=pushTelemetry.udpLoop).start()
>>    Thread(target=cycle.cycleLoop).start()
>> 
>> if __name__ == '__main__':
>>    main()
>> 
>> It basically creates two threads, one which does some local processing and 
>> control, the other which periodically does reporting via udp packets. I use 
>> the dual threads because they both work with a shared serial port at times, 
>> so I have to synchronize access through that.
>> 
>> What I want is to have this startup, after my board has it’s networking 
>> layer up and running (and hopefully a valid ip address by then), and to just 
>> keep running forever
> 
> may be you think about the fork(), eg:
> 
> if __name__ == "__main__":
>    ...other codes, eg. drop root privileges, ...
>    ...check arguments...
>    try:
>      pid = os.fork()
>      if pid > 0:
>          #print "Daemon started (pid: %d)" % (pid)
>          sys.exit(0)
>    except OSError, e:
>      print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno, e.strerror)
>      sys.exit(1)
> 
>    os.chdir("/")
>    os.setsid()
>    os.umask(0)
> 
>    # do second fork
>    try:
>      pid = os.fork()
>      if pid > 0:
>          #print "Daemon started (pid: %d)" % (pid)
>          sys.exit(0)
>    except OSError, e:
>      print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, e.strerror)
>      sys.exit(1)
> 
>    main()

OK, I’m probably going to show my naivety about something simple here…

I thought a “fork” essentially created a memory copy of the original process 
and let it go off running. The problem is, in the bowels of the code executing 
in those loops, I access a single instance of a threading.RLock, so that I can 
avoid both threads trying to do transactions with a single serial port at the 
same time. If I end up with two copies of the base process, unhooked from their 
parent, does that RLock still remain valid between the two? I thought since 
they were complete different copies of the same memory, they would no longer be 
coordinated.

Is this a day where I discover something new?
-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to