I've also played with code now, putting debug output here and there and discovered that we get ETIMEOUT in compositor when we try to update damaged region after out-of-range mode have queried.
There are actually very few places where ETIMEOUT is returned. It can be returned by async_wait_timeout() and fibril_condvar_wait_timeout(). Not sure how it might happen in compositor, as far as I can tell it does not use any routines with timeout.
Are you sure this is not some spurious error again, caused by protocol desynchronization?
BTW, is there a good intro to IPC?
Sure: http://trac.helenos.org/wiki/IPC http://trac.helenos.org/wiki/AsyncSessions
I still doubt that I can understand difference between iid and callid.
I assume you are talking about two variables that usually both have the ipc_callid_t type. This is simple: They both identify an individual received IPC message, so in this case you are working with two IPC messages that have been received and need to be answered eventually. Remember VISUALIZER_ENUMERATE_MODES and IPC_M_DATA_READ, two messages that form one logical IPC call? This is a common pattern.
The iid message usually comes from the main loop of the server connection fibril (the message received by async_get_call() from the big while-cycle) and the callid is usually the subsequent message received in the server method function.
The point is that every received message in HelenOS IPC needs to be answered eventually, thus you need to have a handle to each received message. It's no rocket science :)
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
