[Twisted-Python] Immediate removal of cfreactor

[exarkun at twistedmatrix.com]

On 12:49 pm, itamar at itamarst.org wrote:
>On Sun, 2010-10-31 at 00:51 +0000, exarkun at twistedmatrix.com wrote:
>>Hello all,
>>
>>As reported in <http://twistedmatrix.com/trac/ticket/4652>, some
>>problems have arisen with cfreactor.
>>
>>First, recent versions of Pyrex reject the Pyrex source for the 
>>support
>>modules.  This makes future development on cfreactor difficult 
>>(although
>>Glyph's branch does resolve this problem - or at least appears to).
>
>So, the first problem appears to be fixed.
>>Second, the C source files do not build with clang.  This seems likely
>>to become more important on future versions of OS X (the only platform
>>where this code matters).  Even OS X 10.6 makes clang easily available
>>(according to an Ars Technica article, "Clang is the recommended
>>compiler, and the focus of all of Apple's future efforts."
>><http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/9>)
>
>Have you tried seeing if Cython works with Clang? That ought to be a
>very minor change to our code.

Here are the complete results for all combinations:

        |       trunk        |         branch
        | gcc      | clang   | gcc         | clang
-------------------------------------------------------
Cython  | FTB pyx  | FTB pyx | runLoop err | runLoop err
-------------------------------------------------------
Pyrex   | segfault | FTB c   | runLoop err | runLoop err



  FTB pyx - Failed to build .pyx into .c
  FTB c - Failed to build .c into .so
  segfault - crash during test suite run
  runLoop err - Fails to start reactor because "could not convert 
runLoop"
>>Rather than leaving this to chance, I propose that we remove cfreactor
>>and all supporting code ourselves, immediately (ie, in 10.2 - hi 
>>therve,
>>go faster next time ;).
>
>This violates our deprecation policy... so I suggest we only do it if
>absolutely must, i.e. if Glyph's fixes + Cython don't fix the problem.

Quite so.  It seems like an okay violation to me, since according to the 
table above the best possible behavior cfreactor is able to provide is 
that sometimes it will build and run for a while before segfaulting.

Jean-Paul