Opened 15 years ago
Last modified 8 years ago
#184 new enhancement
Support for ipc_connect_me_to_timeout() would be useful
Reported by: | Jakub Jermář | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | helenos/srv/ns | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
In situations when a client wants to wait for some service for only a limited time, it may be desirable to support timeouts either in the libc or in the naming service.
An example of where this would be useful is the networking code. Without this feature we may see individual clients implement this in their own way,
Change History (6)
comment:1 by , 14 years ago
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:2 by , 13 years ago
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:3 by , 10 years ago
Milestone: | 0.5.1 → 0.5.2 |
---|
comment:4 by , 10 years ago
comment:5 by , 10 years ago
I think that some timeout is necessary, the question is what should be "timeouted". I imagine the situation when (say) location service spawns a task that should provide desired service, however, due to some issues in the task (whatever, halting problem) the task won't never register itself at the location service. I think this is the place where timeout should be applied. Under these circumstances I agree that timeouted ipc_connect_me_to
is the "stop gap".
comment:6 by , 8 years ago
Milestone: | 0.6.1 |
---|
Waiting for a limited time is not the correct solution, it's just a stop gap. What you really want is to block and wait only if the service is actually coming up or will be started eventually.
In your example the system would know that the networking service is enabled in the system, but hasn't come up yet and so it would block the client until the service is up. If the networking service was disabled or failed to start, the client would get an error immediately.
In order to have the knowledge about the existence of some services prior to them being available, there would have to be some kind of service registry / service manager (see 525).