<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Well if your service object isn&#39;t returning to the mainloop or starting<br>up a thread it isn&#39;t going to process the next call until it is done
<br>with the first call.&nbsp;&nbsp; Async calls only have to do with making sure the<br>client doesn&#39;t block.&nbsp;&nbsp;If you don&#39;t want your server to block on long<br>running calls you need to return to the mainloop sooner than later.&nbsp;&nbsp;It
<br>is the same issue as with gui blocking.&nbsp;&nbsp;If you call a function which<br>doesn&#39;t return to the mainloop your application&#39;s gui doesn&#39;t respond.<br>You need to either run your calculations in a thread or defer sending a
<br>reply and doing your calculations in an idle handler.&nbsp;&nbsp;Remember though,<br>you have around 25 seconds to get an answer back to the client if it<br>uses the default timeout.</blockquote><div><br>So, in order for my example to work, each of the functions would need to set a timer, probably to emit a dbus signal, and then return immediately?&nbsp; Normally, server frameworks offer some sort of threaded-reply model so that the core dispatcher doesn&#39;t block when a handler function misbehaves.&nbsp; I take it that&#39;s impossible with the current dbus/glib mainloop, because everything has to be done cooperatively, right?
<br></div><br></div>