On 01:32 am, timothyfitz@gmail.com wrote:
Recently there have been some changes to ThreadedSelectReactor, specifically that it is no longer being considered as a stand alone reactor choice (for example, you will no longer be able to twistd --reactor=threadedselect). This action is desirable since there's no reason for it. As I understand TSR it's broken for that usage anyway; however, I have been warned that TSR is completely broken and shouldn't be used at all. What exactly and specifically are the current problems or at least symptoms of TSR and is it truly broken?
Excellent question. The initial problem is that it has approximately zero test coverage. You cannot run Twisted's test suite using tsr, so who knows what it does? Any change made by any developer to Twisted might break it completely; as a tsr user, you might be the first to notice this circumstance. Not an ideal situation in the least. If tsr is important, I would suggest finding a way to run Twisted's test suite using it. One way to do this is to implement the actual reactor API using a subclass (or some such). Trial might then run the test suite using that reactor subclass. Hopefully there will be support for reactor plugins somewhat soon, but until then you'll need to patch the reactors dictionary at the top of twisted/application/app.py. Jean-Paul
On 10/3/06, exarkun@divmod.com <exarkun@divmod.com> wrote:
If tsr is important, I would suggest finding a way to run Twisted's test suite using it. One way to do this is to implement the actual reactor API using a subclass (or some such). Trial might then run the test suite using that reactor subclass. Hopefully there will be support for reactor plugins somewhat soon, but until then you'll need to patch the reactors dictionary at the top of twisted/application/app.py.
It sounds like even if I were to do this, I could still run into issues with the interleaving being untested. I'm personally using it to interleave with pygame, which is a somewhat common usage. Does it make more sense to write a pygame reactor which then trial can use? (And then setup another buildslave, or at least get it on the reactor buildslave) Would a TSR-only reactor have any purpose outside of running trial and allowing us to narrow down what issues might be causing platform-related bugs?
On Tue, 3 Oct 2006 13:16:22 -0400, Timothy Fitz <timothyfitz@gmail.com> wrote:
On 10/3/06, exarkun@divmod.com <exarkun@divmod.com> wrote:
If tsr is important, I would suggest finding a way to run Twisted's test suite using it. One way to do this is to implement the actual reactor API using a subclass (or some such). Trial might then run the test suite using that reactor subclass. Hopefully there will be support for reactor plugins somewhat soon, but until then you'll need to patch the reactors dictionary at the top of twisted/application/app.py.
It sounds like even if I were to do this, I could still run into issues with the interleaving being untested. I'm personally using it to interleave with pygame, which is a somewhat common usage. Does it make more sense to write a pygame reactor which then trial can use?
That's what I meant. Jean-Paul
participants (3)
-
exarkun＠divmod.com -
Jean-Paul Calderone
-
Timothy Fitz