to py or not to py ?

[Carl J. Van Arsdall]

Tom Plunket wrote:
> Carl J. Van Arsdall wrote:
>
>   
>> Because of the GIL only one thread can actually run at a time.
>>     
>
> I've recently been wondering about this, since in the work I do, a lot
> of time is spent doing disk I/O.  So if I want the UI to remain
> responsive, I could spawn an IO thread to handle requests, and do a
> pretty simple "just whack new requests onto the queue" without locks
> since I'm guaranteed to not have the IO thread read at the same time
> as the requestor thread?
>
> ...what exactly constitutes an atomic operation in Python, anyway?
>
>   

Well, although only one thread can run at a time due to the GIL you 
can't accurately predict when the GIL is going to be released and 
therefore you don't know when another thread is going to pick up and 
start going (GIL is released on every so many byte instructs - correct 
me if i'm wrong, certain operations that have a bit to do with IO, and 
modules you wrote yourself where you manually release the GIL using 
macros provided in the C API).  If you have your own data structure that 
is shared among threads you can use the threading modules 
synchronization constructs to get the job done, using locks, conditions, 
and events.  Queue.Queue is also a good way to go about communicating 
with threads.



> e.g.
>
> class IoThread:
>    # ...
>
>    # called from the other thread...
>    def RequestFile(self, name):
>       self.fileQueue.append(name)
>
>    # called during the IO thread
>    def GetNextFile(self);
>       next = self.fileQueue[0]
>       self.fileQueue.pop(0)
>       return next
>
> ?
> -tom!
>   


-- 

Carl J. Van Arsdall
cvanarsdall at mvista.com
Build and Release
MontaVista Software