In order to simply porting the iocore/net code which deals with polling was encapsulated. This means that the structure of the code changed although the actual calls sequence should be identical. The TCP codepaths have been tested as well as DNS but the raw UDP hasn't been, primarily because non of the existing codebase uses it.
So, while it is not as safe as simple #ifdef's it is more a question of moving interfaces rather than changing core functionality. I would suggest that those who are worried read the patch. The OSX part of the patch moves some initialization code around because OSX doesn't initialize the thread library till after global C++ constucters are called (something I have seen on other platforms). That is a potentially larger change but necessary for an OSX port and for similar platforms. john On 12/18/2009 1:33 PM, Leif Hedstrom wrote: > On 12/18/2009 02:27 PM, John Plevyak wrote: >> Based on discussion in IRC: >> >> The OSX + libev + iocore/net encapsulation patch could >> be applied to the trunk to bring this port and potentially >> ease others based on libev. This would require adding >> the libev code (at least temporarily) into the code tree >> (I say temporarily because we might through patches to libev >> or code changes eliminate the requirement to patch the libev >> source). >> > > As long as this is "safe" when disabled (which I assume is the default), > +1. When you say there's more risk, why is that? If all the libev code > is #ifdef'd, how can it have any risk associated with it when it's > disabled? Or is there other code that changes, which is not #ifdef'ed ? > > Cheers, > > -- Leif
