Differences in select functions in Windows and Linux

Differences in select functions in Windows and Linux

Thanks to the Lord, Windows has also implemented the select function, which makes our cross-platform business at least smooth. However, due to the rebellious nature of Windows infiltration into the bone marrow, he always has to make some difference with the implementation of UNIX, making you helpless. First of all, the parameter Interface Design of the select function in Windows is quite different from that in Linux. This is discussed in my "select function with extremely poor design". Relatively speaking, in terms of parameter design, Windows is much better than Linux. This time we will talk about their functional differences.

1. Differences in processing when no handle is triggered

The latest New refactoring code found that the CPU of the program is very high in Windows. The test found that the select function is not waiting, return-1. Our code used the Rector mode, select is used as the reactor to handle Io events, and sleep is used when no IO events exist. However, our business server does not have any Io handle to process, so it is equivalent to calling

Select (0, null, wait_timeval );

In Linux, this method is equivalent to sleep, but in windows,-1 is returned, and the parameter you pass is incorrect. After querying msdn, we found the following descriptions.

Microsoft MSDN:Any two of the parameters, readfds, writefds, or exceptfds, can be given as null. At least one must be non-null, and any non-null descriptor set must contain at least one handle to a socket.

 

Therefore, in Windows, it is not feasible to use select as the sleep method,

The method to correct the problem is also very simple. We have an OS Adaptation Layer in which we repackage the select function. When the three handle arrays are null, we directly call :: sleep, this is OK.

It is worth noting that ace does not solve this problem either in this case, or it can be regarded as an ace trap. However, because the replacement y queue in the Rector packaging of ACE registers a handle to the SELECT statement (the strange thing is that I have used the ace_has_reactor_icationication_queue macro, this macro should allow notify to use Message Queue instead of network communication mode), so you will not find this problem by default. When you close the notify Queue (reactor's open function parameter ), the problem also occurs.

2 non-blocking connection failure trigger difference

On the last day before the holiday, yunfeiyang suddenly told me that the communication program was not re-connected in windows and located together, in Windows, it is found that non-blocking connect is required for connections from other servers. After the connection fails, no event is triggered.

Look at the code carefully. Our code is after the connect failure, if the returned error is ewouldblock, it is considered that a non-blocking connection is successfully initiated. Wait for the write event and read event. If the connection is successful and the connection fails, the read/write event should be triggered (my code preferentially processes read events ). This is consistent with the UNIX Network Programming: Volume 1, and the test is normal in Linux. However, in windows, read/write events are not triggered after a non-blocking connection fails.

I suddenly remembered that the earliest communication server used ACE as the underlying layer. I did not have this problem during the tests. As a result, I found a small example of the test and started debugging. If the connection fails, Ace's ace_select_reactor can trigger the handle_close event. So I was a little dizzy, and then further checked the code to find that there was such a paragraph when the ace was registering an event.

// Code for event registration: // handle T (and connect on Win32) flag will place the handle in // The handle t set. if (ace_bit_enabled (mask, ace_event_handler: effect_mask) # If defined (ace_win32) | ace_bit_enabled (mask, ace_event_handler: connect_mask) # endif/* ace_win32 */) {(handle_set.ex_mask _. * ptmf) (handle );}

It has special processing for the Win32 platform. I immediately flipped through msdn and found that the handle to the exception event is described as follows: Sure enough, the processing of the Microsoft platform is different from that of Linux, if a non-blocking connection fails, an exception event is triggered.

Microsoft MSDN:exceptfds:    If processing a connect call (nonblocking), connection attempt failed.    OOB data is available for reading (only if SO_OOBINLINE is disabled).

 

 

In addition, this problem cannot be blocked at the underlying layer (because the underlying layer does not know what the purpose of triggering an event is). This difference can only be solved in the upper layer encapsulation.

If you have time to summarize some articles on cross-platform Linux + windows, it is estimated that the title can be written as Microsoft on Dog Day.

 

[The author of this article is Yan du Han tan, in the spirit of freedom, you can be in the profit of the complete reprinted this document, reprinted Please attach blog link: http://www.cnblogs.com/fullsail/ or http://blog.csdn.net/fullsail, the negative is a dollar, every figure one hundred no. Double the Baidu Library price]