Fall 2010 Task Force Discussions-Background Notes

At TMC's 2010 Fall Meeting, the RP 1210 Update Task Force recommended changing this function somewhat because the Task Force was looking more closely at multi-application capable VDA devices and the issues involved with that capability. The topic of BLOCKING_IO versus NON_BLOCKING_IO was the biggest topic, leading to the change of this function. The Task Force also discussed changing the nlnfoSize  parameter to something that does not have to be changed again.

In RP 1210A, if you read the specification closely, if you called with BLOCKING_IO set, the VDA drivers would not come back unless there was a change in the low byte for the protocol the client was connected to (the "activated/traffic-detected 'ever'/BUS_OFF" byte). This meant that only if the bus status had changed, would the function return. An application could call this with BLOCKING_IO and it would never return unless the adapter was disconnected or reconnected. Since this was before the "threading model" became popular, most apps just called it with NON_BLOCKING_IO in a polling fashion.

In RP 1210B, if you called with BLOCKING_IO set, the VDA drivers would abide by the "BLOCKING TIMEOUT" variable (infinite was assumed), but the low protocol bytes were changed to indicate if traffic had been seen in the past second (instead of traffic 'ever' having been seen). This meant that only if traffic was detected one second and not the next, or the VDA was unplugged and re-plugged in, would the function return. Threading was popular when this was balloted, but most applications kept calling it as NON_BLOCKING_IO in a polling fashion while some VDA vendors just implemented it as NON J3LOCKINGJO anyway.