[zeromq-dev] [PATCH] STL use in select.hpp/cpp

Martin Sustrik sustrik at 250bpm.com
Mon Nov 1 09:59:06 CET 2010


If you send the patches for alternative polling mechanisms, I can test them.

The latency results are no likely. The algorithm kicks in when there's 
large number of connections, which is not the setup you normally use for 
measuring latency.

Martin

On 11/01/2010 09:55 AM, Mikael Helbo Kjær wrote:
> Unfortunately yes I am on Win64 (heh just to be contrary), but I could write some of the code for you if you wanna pick what needs done, but I couldn't compile it unless it is general. However the method is quite simple. Just the Boolean returning function. If you have more complex loops I suggest making the remove_if call function into a functor with member variables (such as I did in my first example even if it was on a map on which you should NOT apply this idea).
>
> Also if you get any interesting results latency or throughput wise from this I would be glad to hear it. I doubt it (it'll mostly reduce memory churn from copying and CPU use but oh well) but I can hope.
>
> /Mikael
>
>    
>> Mikael,
>>      
>>> Well it wouldn't remove the need for the is_retired_fd function,
>>>        
>> because std::remove_if can only call a function takes the data type of
>> its collection as its only parameter which is fd_entry_t in this case.
>> So because fd_entry_t is not a central type (it is defined in several
>> places internally and different to poll, devpoll and select). Basically
>> remove_if needs to call a function akin to this:
>> bool<function_name>(const<collection_data_type>   &name).
>>      
>>>        
>> A-ha. I've missed that bit.
>>
>> I'll apply your patch.
>>
>> Now, we should fix the problem in alternative pollers
>> (poll/epoll/devpoll/kqueue). I assume you are on Win32 where only
>> select
>> is available, right?
>>
>> Martin
>>      




More information about the zeromq-dev mailing list