Hi Peter,
I only verified this by checking it out. Here is the code
import sys
sys.path.append('c:\\python23\\lib\\site-packages\\serial')
import thread #This module provides low-level primitives for
working with multiple threads
import threading #This module constructs higher-level threading
interfaces on top of the lower level thread module.
import serialwin32 #Python Serial Port Extension for Win32,
Linux, BSD, Jython; serial driver for win32; see __init__.py
import socket #Low-level networking interface
import binascii #Convert between binary and ASCII
def NetworkToSerial(input):
s.write(binascii.unhexlify(input))
print "SENT: %s" % input # %s: if command is
not string format to string
def SerialToNetwork():
result = s.read(12)
print "RECEIVED:"
print binascii.hexlify(result)
s = serialwin32.Serial ()
s.port = 0 #COM1
s.baudrate = 115200
s.databits = 8
s.timeout = None #None=wait forever; 0=return
immediately on read; x = x seconds
s.open()
command = "0b02ff0512340000000255aa"
sthread = threading.Thread(target=NetworkToSerial(command))
rthread = threading.Thread(target=SerialToNetwork)
sthread.start()
rthread.start()
sthread.join(5)
rthread.join(5)
s.close()
and it does exactly what I want it to do, so I guess it's ok...
Thank you for your help!
Bye
Silke
Peter Hansen <pe***@engcorp.com> wrote in message news:<U9********************@powergate.ca>...
Silke wrote: I already found a solution using 'threading' instead of 'thread' :-)
Are you positive that is really a solution? If the original
problem was truly because of a thread-safety issue, then it's
most likely, I think, that it was a race condition and that
it could very well re-appear in the future.
The "threading" module is mostly just a higher level API on
top of the "thread" module, so that change alone seems unlikely
to solve the issue, unless there is code in serialwin32 specifically
to do the proper locking when the threading module is used...
-Peter