Ok, I did some tests on the timeout problem now. Here are the results: 1. The proposed patch (moving the connection.setTimeout() call after the connection.receive() call) is a *huge* improvement. Instead of ~15 secs, my testcase runs in fractions of a second. 2. The timeout (connection.setTimeout) and the alarm (DBusServer::resetTimer) times are related. Apparently, the SIGALARM is only handled outside the connection.receive() function, when the main loop of DBusServer.cc is executed.
Esp. result 2 makes the whole signal/alarm logic questionable, as this could easily be moved into the main loop. Ideally, the connection.receive() should handle the timeout and return either with a message (to be handled) or a timeout (shutdown service). But coding DBus without glib seems to be black magic after all ... ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
