In my opinion we should make a note that pygr 0.8 is not thread safe, use the temporary file solution for now and put thread safety on a to do list for 1.0.
Having proper concurrency would be a big plus for bioinformatics, since the machines are moving multi-core. Even with PIL my threading code was utilizing ~150% of cpu on a dual core machine. This is because blastall was running in a separate process scheduled on a separate core. Now when we go and do more graphical stuff (I'll add more thoughts/ideas on this later) then threading would be very important for usability. So eventually thread-safety should happen. Currently, the key conflict with threads is that mutable and immutable operations are intermixed. For instance, reading a sequence from a sequence database feels like an immutable operation, however, since we are doing caching in the background, the operation does change the internal state of the database object. Hence, two threads cannot use a single sequence database object even for reading. I am sure there are other examples of this unintuitive behavior with respect to mutability elsewhere. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-dev@googlegroups.com To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
