This is a great point in any environment. In a previous job I had written a new IPC library for a server application, and I had to learn the hard way that you want reasonable timeouts for IPC...
This is a great point in any environment.
In a previous job I had written a new IPC library for a server application, and I had to learn the hard way that you want reasonable timeouts for IPC requests, whether that's for a socket, a pipe, thread synchronization... anything, really.
I'm dealing with this now, and it's no fun. (Well it's fun in a way. 🙂 It ends up being more about solving a puzzle than about doing the actual work that needs done.) I'm not even doing it over...
I'm dealing with this now, and it's no fun. (Well it's fun in a way. 🙂 It ends up being more about solving a puzzle than about doing the actual work that needs done.)
I'm not even doing it over the network - just IPC to another process on the same machine. But you have most of the same issues. If something needs to be done synchronously, you have to pick an arbitrary amount of time to wait. If it does time out, how do you handle it? Return an error or throw an exception. But then what if a response comes in after your timeout has fired? You need a mechanism to say to ignore it, or to cut off the communication once you've timed out. It's quite challenging.
And if you do it asynchronously, you hit some of the same problems (at some point you have to decide you're not getting an answer). But you also hit other design problems. Like how do I do this task asynchronously? Can I do something else while I wait for the reply? Does it make sense to do this asynchronously if I can't really do anything else until I get the reply? etc.
This is a great point in any environment.
In a previous job I had written a new IPC library for a server application, and I had to learn the hard way that you want reasonable timeouts for IPC requests, whether that's for a socket, a pipe, thread synchronization... anything, really.
I'm dealing with this now, and it's no fun. (Well it's fun in a way. 🙂 It ends up being more about solving a puzzle than about doing the actual work that needs done.)
I'm not even doing it over the network - just IPC to another process on the same machine. But you have most of the same issues. If something needs to be done synchronously, you have to pick an arbitrary amount of time to wait. If it does time out, how do you handle it? Return an error or throw an exception. But then what if a response comes in after your timeout has fired? You need a mechanism to say to ignore it, or to cut off the communication once you've timed out. It's quite challenging.
And if you do it asynchronously, you hit some of the same problems (at some point you have to decide you're not getting an answer). But you also hit other design problems. Like how do I do this task asynchronously? Can I do something else while I wait for the reply? Does it make sense to do this asynchronously if I can't really do anything else until I get the reply? etc.