6:21 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=6376
--- Comment #4 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-10 23:21:50 PST
---
This should work. Getting out of g_main_loop_run() is always a bit
tricky. For
example, Session::Abort() might have been called.
Yes, that's true.
> if(id == m_id && m_reqStatus == "response") {
> response = m_response;
> clear m_id, m_response
> send signal InfoRequest("done")
> return true;
> }
> // timeout or response status is not expected, return false
> return false;
> }
The caller might have to know whether a timeout occurred (=> use default reply)
or whether some other event occurred (=> handle that event).
Yes, maybe an enum
value could be returned.
There's one problem here: what if such a different event
(Session::Abort(), new
data to process from a connection) causes DBusServer::handleInfoRequest() to
return? There's no way how the caller can resume waiting for a response or tell
DBusServer that the response is no longer needed. Additional API calls would be
needed for that.
That's right. A series of APIs may be provided without
blocking and a 'wait'
API is used to let callers blocked.
Perhaps it would be simpler to not make
DBusServer::handleInfoRequest()
blocking in the first place and design the API so that an info request is
started, checked and cancelled without blocking?
Some initial APIs are provided
here(arguments may not be accurate):
string infoRequest(key, parameters) /// start a info request, no blocking
int check(id) /// check whether it is ready, no blocking
void getResponse(&response) /// get response if ready, no blocking
void cancel(string id) /// no blocking
int wait(id, &response) /// wait until response is gotten, int indicates
timeout or other
however, there is still a problem here. Like you said, when one caller is
waiting, if other events arrive, and their handlers make loop quit. How to deal
with it? I think there should be 2 categories,
1) For Session::Abort(), the waiting must quit the loop and return.(session
need be aborted.
2) For Connection, there may be a message arrived and the wait() should still
wait for the response I think.
But it seems DBus server currently has no capability of looking up this kind of
information.
Also, only one info request can be pending at any time. This is
probably a
valid simplification, but could be avoided by introducing a handle for it which
is passed around via smart pointers. Destructing the handle would automatically
cancel the request, which is in line with treating a pending info request as an
active resource.
I don't quit understand this sentence. so we could allow many
requests a time
since the above non-blocking APIs.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.