OSX + libev + iocore/net encapsulation into trunk? please vote on inclusion in trunk

[John Plevyak <jp...@acm.org>]

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).

Advantages:
- OSX port
- potentially ease porting to other platforms

Disadvantages:
- more code changes == risks
- clutter in tree?

Note: it is checked in to branches/dev changeset 892325,
if you would like to look at it that way.

The patch is also available at:

https://issues.apache.org/jira/secure/attachment/12428485/osx-etc.patch


Please vote on inclusion.

john

Re: OSX + libev + iocore/net encapsulation into trunk? please vote on inclusion in trunk

[John Plevyak <jp...@acm.org>]

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

Re: OSX + libev + iocore/net encapsulation into trunk? please vote on inclusion in trunk

[Leif Hedstrom <zw...@apache.org>]

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