Roadshow and WHDLoad

[daxb]

Sadly, there is no truly reliable way to shut down the Roadshow TCP/IP stack through the "NetShutdown" command. It may succeed but it may not succeed, for reasons which are hard to explain. Basically, "NetShutdown" asks every program currently using it nicely (under the circumstances) to stop doing so and waits for all of them to sign off. This is not always attainable because, for example, the original design of the AmiTCP TCP/IP stack did not plan for client software to listen to such requests. Quitting is not mandatory, it is "voluntary".

Maybe you can add a workaround like a FORCE Option for NetShutdown. So it will shut down Roadshow after the timeout. It may result in an unstable system but could help in some cases. If you document this it should be enough. The user is then responsible if he uses the FORCE option. I guess it would be better at least then the user tries to use Scout/XOpa or whatever tool to kill Roadshow. Unfortunately, we have no resource management that would help.

[olsen]

Sadly, there is no truly reliable way to shut down the Roadshow TCP/IP stack through the "NetShutdown" command. It may succeed but it may not succeed, for reasons which are hard to explain. Basically, "NetShutdown" asks every program currently using it nicely (under the circumstances) to stop doing so and waits for all of them to sign off. This is not always attainable because, for example, the original design of the AmiTCP TCP/IP stack did not plan for client software to listen to such requests. Quitting is not mandatory, it is "voluntary".

Maybe you can add a workaround like a FORCE Option for NetShutdown. So it will shut down Roadshow after the timeout. It may result in an unstable system but could help in some cases. If you document this it should be enough. The user is then responsible if he uses the FORCE option. I guess it would be better at least then the user tries to use Scout/XOpa or whatever tool to kill Roadshow. Unfortunately, we have no resource management that would help.

I am afraid there is no halfway house between the TCP/IP stack running and it not running

The design of AmiTCP never took into account that you might want to stop the TCP/IP stack without the willing cooperation of the programs which are still holding onto it and are expecting a specific well-defined behaviour.

Roadshow attempts to do as much as can be done without breaking the implied and explicit rules of the TCP/IP stack, how client software uses it, and how the network device drivers make use of it. In the end that may not be enough because of the unpredictability of the many moving parts involved.

For example, some network device drivers cannot be closed safely, even if all the currently queued I/O requests have been cancelled and taken out of service (Amiga device drivers tend to be a very mixed bag, which goes double for network device driver and in particular legacy drivers for legacy hardware which never received updates and bug fixes). Client code may still be executing TCP/IP kernel code, waiting for a condition change which will never arrive, but removing it by force from that queue may render the signal semaphore which polices access to kernel data inconsistent. Roadshow is chock full of such interlocking, concurrent operations and not just the TCP/IP kernel.

The "NetShutdown" command is limited to delivering safe and predictable outcomes. Either it succeeds or it fails at shutting down the network. If it fails, then this needs to be respected and handled accordingly. The only safe way to avoid not being able to shut down the network is not starting it in the first place and nothing I could do to the TCP/IP kernel code could change that.

[daxb]

Ok, I understand and back in the days when I used 56k modem I had noticed that sometimes MiamiaDX couldn't go off for some unknown reason. Further, I think it (FORCE option) wouldn't help in jjmarcos case. The WHDLoad options should help more.

jjmarcos you could try to find out what is the reason that stops Roadshow shutdown and then just avoid it. However, this might not be possible.