should libmodbus really do a reconnect on error with a TCP connection?

While attempting to figure out why my test application would wait 3 to 190 seconds to return from libmodbus calls, I tracked it down to the behavior of error_treat.

I expect that with serial IO, the tcflush command is probably fast.
I understand the desire to have a process setup by modbus_init_tcp behave the same as one setup by modbus_init_rtu, but they do not because the TCP connect can hang (for 3 to 190 seconds in practice) if the TCP connected rtu is not responding, which is a bad thing in a near/soft real time system.

I have a couple of related questions before I make a bug and a patch (or two).

1) would it be more acceptable to have modbus_init_tcp take another input indicating the desire to have error_treat skip the reconnect (so folks can continue on with the behavior they have now _or_ choose my route), or remove the TCP reconnect from error_treat altogether?

2) at many places in the code (following the TCP route, not serial) there are calls to close(mb_param->fd) but mb_param->fd is left containing the value it had before the call to close, and there are no checks in other parts of the code to make sure they have valid file-descriptors before calling read||write. would a patch that places "mb_param->fd=-1;" after each close call, and checks for "fd>=0" before each read||write be accepted?