在CAN和LIN相关的开发库里，不可避免的会出现“收”和“发”的函数。如何快速有效的处理数据，是开发中重要的事项。
但实际上单路CAN由于波特率的限制，数据量并不会很大：以常用的500k为例，如果按照总线负载率为30%左右，那么需要在1ms处理1~2次数据即可。相比之下常用的以太网一般都要在100M的速率以上了。
因为系统的底层，例如WINDOWS，在处理文件、串口等使用的是同样的函数，所以CAN、LIN处理起来可以运用这些相关的经验。回归到正题，读写函数可以分为阻塞函数和非阻塞函数两种，它们处理起来的方式是不一样的。
阻塞函数(blocking)：在执行时会阻塞当前线程，通常会有一个超时时间。
非阻塞函数(non-blocking)：不会阻塞当前线程，直接返回结果，通常会有一个对应的缓存。
让我们举两个例子说明：
在UDS的API中获取ECU返回的数据采用阻塞函数。例如，我们在用27服务获取seed，如果我们没有成功获取seed，那么接下来的步骤也无法进行下去。所以阻塞函数会迫使我们去等待结果；如果执行失败，需要做错误处理，例如重新尝试进行获取。
如果阻塞函数的超时时间设置为0，就会和非阻塞函数类似（有些阻塞函数超时时间为0，可能意味着永远也读不到数据了，因为它们总是想要读取来自“未来”的内容）。
在底层的basic API中，CAN的接收采用了非阻塞函数，设备将把读到的数据放到缓存里，而函数将从缓存里读取数据。如果缓存里没有数据，函数会立刻返回无数据，而不会等待“不确定的”下一个数据。也就是说无论何种情况，函数都会立刻返回结果。
在我们处理CAN数据时，可以周期性（例如20ms）读取数据，读到无数据之后，做其它的事情，例如通过dbc获取信号值并显示。函数不会等待20ms直到新的CAN帧出现在总线上，也防止了丢帧的情况。因为普通的CAN通信，我们无法在程序层面判断何时会接收到新的数据。
另外，有时我们也会想要保证数据是“新的”，而不是躺在缓存里不知道多久之前的内容，那么在读取数据前先清空缓存会是一个不错的选择。
