On 25/08/2010 19:36, Joel Koltner wrote:
I have a multi-threaded application where several of the threads need to write to a serial port that's being handled by pySerial. If pySerial thread-safe in the sense that pySerial.write behaves atomically? I.e., if thread 1 executes, serport.write("Hello, world!") and thread 2 executes serport.write("All your bases are belong to us!"), is it guaranteed that the output over the serial port won't "mix" the two together (e.g., "Hello All your bases are belong to us!, world!") ?I looked at the source code, and the write method eventually boils down to calling an the OS's "write" function, which presumably ends up being a call to a C function. Given the global interpreter lock -- and particularly how C functions can't be interrupted by the Python interpreter at all -- it sure seems as though everything is copacetic here?
Don't assume that just because it calls a C function the GIL won't be released. I/O calls which can take a relatively long time to complete often release the GIL.
If not I can just add a queue and have everything go through it, but of course I'd like to avoid the extra code and CPU cycles if it isn't at all necessary.
Unless I know that something is definitely thread-safe, that would be the way I would go. -- http://mail.python.org/mailman/listinfo/python-list
