Subject: [DMM] Blocking vs non-blocking function behavior

From: "Moses, Danny" <[email-masked]>
Date: Mon, 16 Jan 2017 08:42:17 +0000

Hi,

Another concern that was raised is regarding the blocking vs non-blocking behavior of the setsockopt() function with the new OnDemand feature.
Lorenzo, in one of his comments, suggested to consider adding a new function with a blocking nature, in order not to surprise application developers with a blocking behavior to setsockopt() - which is a non-blocking function.

I agree that this may surprise and confuse application developers. I would like to suggest two alternatives for a solution:

1.      Add a new function (setsockoptblocking()) which has a blocking behavior

2.      Add a new option type to setsockopt() - IPV6_MOBILITY_ON_DEMAND - and describe its possible blocking behavior

The advantage of adding a new function, is the clear separation of the behavior. Setsockopt() always returns immediately (does not cause packet exchange), and setsockoptblocking() may block execution if it requires packet exchange to be able to complete its functionality (for example, when it requires a new Session-lasting IP prefix from the network).

The disadvantage is the definition of a new function to the long list of existing functions - which adds to the complexity of the Socket API (which is already quite complicated).

Adding a new option to the setsockopt() may be a good compromise. We can document that the new option may cause a blocking effect. It also clearly separates the functionality of OnDemand support from the rest of the options.

I also want to point out that so far I did not see any clear separation between blocking and non-blocking functions in the Socket API. It's true that some functions have a blocking nature (like connect() in TCP) and some don't but the separation of functions did not take that in account. I believe that there are functions that may or may not block execution depending on different situations and that setsockopt() will not be the first one to do so. So our extension to the API is still consistent with the current design.

What do you think?

Danny
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.