Menu
▾
▴
dbus-cplusplus-devel
|
From: Mat <mat...@gm...> - 2009-06-24 06:11:54
|
Hello everyone, I'm writing a program[1] which use D-Bus C++ as IPC library. It works quite good on Linux.-- Thanks to all developer's great effort to D-Bus C++. -- I wish to port the program from linux to wndows which depends on D-Bus C++, however I don't know how to use/port D-Bus C++ on win32 platform. Could someone help me , or give me some hints or suggestions to solve this problem? sincerely, Mat. [1]. http://code.google.com/p/inkboardng/ |
|
From: Andreas V. <li...@br...> - 2009-06-26 20:20:07
|
Am Wed, 24 Jun 2009 14:10:48 +0800 schrieb Mat: Hello Mat, I'm happy that DBus-C++ is useful for your application. I assume it would simply compile on win32 as long as Dbus itself is available. Some time ago I used MinGW to compile a autotools based application. Currently I would only develop on Windows for money. It's bad to waste my spare time with windows. :-) But if you've some errors related to Dbus-C++ while compiling with windows that ask here. Maybe someone could help you. regards Andreas > Hello everyone, > > I'm writing a program[1] which use D-Bus C++ as IPC library. > It works quite good on Linux.-- Thanks to all developer's great > effort to D-Bus C++. -- > > I wish to port the program from linux to wndows which depends on > D-Bus C++, however I don't know how to use/port D-Bus C++ on win32 > platform. Could someone help me , or give me some hints or > suggestions to solve this problem? > > sincerely, Mat. > > [1]. http://code.google.com/p/inkboardng/ |
|
From: Bruce, H. <hen...@in...> - 2009-07-02 20:50:43
|
Andreas, Thanks for the reply. It looks like I used the default main loop. I'll look into swapping for the glib main loop. I guess the glib sample shows me how to do this ? This is encouraging news, as I also have to support Visual Studio builds (using WinDBus) and my initial port didn't go well, but it may have been the other main loop options that caused the problems. FYI dbus-glib Visual Studio port went smoothly and is running fine, so I'm tempted to go with the "bird in the hand" option. I'll do some digging and get back to you. Henry -----Original Message----- From: Andreas Volz [mailto:li...@br...] Sent: Thursday, July 02, 2009 12:45 PM To: dbu...@li... Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails Am Tue, 30 Jun 2009 12:46:17 -0700 schrieb Bruce, Henry: Hello Henry, To be honest I know this comment, but never experienced this error. And I use Dbus-C++ for a heavy communicating application. Which main loop integration do you use? Try the Ecore or Glib loop. The default one is buggy. regards Andreas > All, > > I have been evaluating dbus-c++. I really like the design - it makes > good use of C++ and is much easier to use the dbus-glib. I also like > the use of XML service description files. When I built and ran the > "echo" sample, the client failed after a few requests with a "not > enough memory" exception. When I looked at the source for > echo-client.cpp I saw the comment "For some strange reason, libdbus > frequently dies with an OOM". Sure enough, it had. > > I'd really like to use dbus-c++, but it just doesn't seem stable > enough. Has anyone root caused this behavior? > > Hoping that someone will save me from dbus-glib, > > Thanks, > > Henry Bruce > > > > ------------------------------------------------------------------------------ > _______________________________________________ > dbus-cplusplus-devel mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel > ------------------------------------------------------------------------------ _______________________________________________ dbus-cplusplus-devel mailing list dbu...@li... https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel |
|
From: Mat <mat...@gm...> - 2009-07-06 03:41:01
|
Hi Henry Bruce, I encountered the same problem, too. === execute result === terminate called after throwing an instance of 'DBus::Error' what(): Not enough memory Aborted ================== When I execute more times, it could connect successfully, and when I use other dbus-client to send request, like "d-feet" and "dbus-send", it works fine. So I guess the problem may caused by the client implementation. === machine === Linux localhost 2.6.30-gentoo-r1 #3 SMP Sun Jul 5 22:09:23 CST 2009 i686 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux gcc version 4.3.2 ============== === top === 4813 mat 20 0 132m 1584 1268 S 0 0.1 0:00.01 lt-echo-client- ========== Hope this helps, sincerely, Mat. On Fri, Jul 3, 2009 at 4:25 AM, Bruce, Henry <hen...@in...> wrote: > Andreas, > > Thanks for the reply. > > It looks like I used the default main loop. I'll look into swapping for the > glib main loop. I guess the glib sample shows me how to do this ? > > This is encouraging news, as I also have to support Visual Studio builds > (using WinDBus) and my initial port didn't go well, but it may have been the > other main loop options that caused the problems. > > FYI dbus-glib Visual Studio port went smoothly and is running fine, so I'm > tempted to go with the "bird in the hand" option. > > I'll do some digging and get back to you. > > Henry > > > -----Original Message----- > From: Andreas Volz [mailto:li...@br...] > Sent: Thursday, July 02, 2009 12:45 PM > To: dbu...@li... > Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails > > Am Tue, 30 Jun 2009 12:46:17 -0700 schrieb Bruce, Henry: > > Hello Henry, > > To be honest I know this comment, but never experienced this error. And > I use Dbus-C++ for a heavy communicating application. > > Which main loop integration do you use? Try the Ecore or Glib loop. The > default one is buggy. > > regards > Andreas > > > All, > > > > I have been evaluating dbus-c++. I really like the design - it makes > > good use of C++ and is much easier to use the dbus-glib. I also like > > the use of XML service description files. When I built and ran the > > "echo" sample, the client failed after a few requests with a "not > > enough memory" exception. When I looked at the source for > > echo-client.cpp I saw the comment "For some strange reason, libdbus > > frequently dies with an OOM". Sure enough, it had. > > > > I'd really like to use dbus-c++, but it just doesn't seem stable > > enough. Has anyone root caused this behavior? > > > > Hoping that someone will save me from dbus-glib, > > > > Thanks, > > > > Henry Bruce > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > dbus-cplusplus-devel mailing list > > dbu...@li... > > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > dbus-cplusplus-devel mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > dbus-cplusplus-devel mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel > |
|
From: Meier, A. <and...@sc...> - 2009-10-23 15:14:37
Attachments:
dbus-cplusplus-echo-client-patch-1
|
In the past week I worked on the echo example and tried to figure out why it did not work. It occurred to me that the multi threading cannot work since libdbus does a poll and dbus-cplusplus does a poll as well on the same file descriptor which cannot be safe. My echo-client blocked for 25 secs after a client issued a Hello request. The server's response let the dispatcher return from the poll call. The following watch_ready read the message from the socket but had it not ready to dispatch before the client issued its blocking poll. Then the response was ready but the client could not be woken up. My first idea was that we must somehow be able to wake up the client, then I realized that this code was located in libdbus. The second idea was to have a separate connection for each server and client object. To ensure that the dispatcher is not polling the client connections and accidentally receive responses an additional dummy dispatcher must be created and set as default_dispatcher while creating the client connections. Please have a look at my patch. It fixed the echo example for me. Best regards, Andreas > -----Original Message----- > From: Andreas Volz [mailto:li...@br...] > Sent: Dienstag, 14. Juli 2009 17:48 > To: dbu...@li... > Subject: [sls][heur] Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails > > Am Wed, 8 Jul 2009 11:04:50 -0700 schrieb Bruce, Henry: > > Yes, the example is bad. If someone provides a better one I'll commit > it. > > regards > Andreas > > > Sorry - just realized that applications set the main loop type. So > > echo sample still fails with Glib main loop. Maybe best just to > > remove it from the source tree. A sample that doesn't work is a > > barrier to adoption. > > > > The properties sample works just fine. Not sure why the client needs > > to spawn a thread. Can someone explain? > > > > I've got a Visual Studio build with the Glib main loop and the > > "properties" sample, but client / server comms are not working. Dbus > > monitor sees the client request, but server doesn't pick it up. I'll > > keep debugging. > > > > Henry > > > > > > -----Original Message----- > > From: Bruce, Henry [mailto:hen...@in...] > > Sent: Tuesday, July 07, 2009 12:05 PM > > To: dbu...@li... > > Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails > > > > Thanks to all who replied to my email. I've been digging deeper and > > have some questions and comments > > > > 1. Does "main loop integration" apply to client and server > > applications and/or the binding library itself (i.e. dbus-c++ library) > > > > 2. I switched to echo client and server applications to use the Glib > > main loop but still see the same "OOM" error on the client. As the > > dispatch enter and leave method are stubbed out in the Glib > > implementation, I created my own main loop in the client and server > > applications. > > > > 3. Is it possible to change the main loop used by the binding? If so, > > are there instructions on how to do this ? I tried swapping out > > eventloop.h and for glib-integration.h in dispatcher.h and changing > > type of default_dispatcher accordingly, but got compiler errors > > (couldn't find any of the "Internal" sub classes). > > > > 4. If I can work out how to do (3) for Glib, I can see a route to > > Visual Studio port. > > > > Henry > > > > > > > > -----Original Message----- > > From: Andreas Volz [mailto:li...@br...] > > Sent: Thursday, July 02, 2009 12:45 PM > > To: dbu...@li... > > Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails > > > > Am Tue, 30 Jun 2009 12:46:17 -0700 schrieb Bruce, Henry: > > > > Hello Henry, > > > > To be honest I know this comment, but never experienced this error. > > And I use Dbus-C++ for a heavy communicating application. > > > > Which main loop integration do you use? Try the Ecore or Glib loop. > > The default one is buggy. > > > > regards > > Andreas > > > > > All, > > > > > > I have been evaluating dbus-c++. I really like the design - it makes > > > good use of C++ and is much easier to use the dbus-glib. I also like > > > the use of XML service description files. When I built and ran the > > > "echo" sample, the client failed after a few requests with a "not > > > enough memory" exception. When I looked at the source for > > > echo-client.cpp I saw the comment "For some strange reason, libdbus > > > frequently dies with an OOM". Sure enough, it had. > > > > > > I'd really like to use dbus-c++, but it just doesn't seem stable > > > enough. Has anyone root caused this behavior? > > > > > > Hoping that someone will save me from dbus-glib, > > > > > > Thanks, > > > > > > Henry Bruce > > > > > > > > > > > > ------------------------------------------------------------------------ ------ > > > _______________________________________________ > > > dbus-cplusplus-devel mailing list > > > dbu...@li... > > > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel > > > > > > > ------------------------------------------------------------------------ ------ > > _______________________________________________ > > dbus-cplusplus-devel mailing list > > dbu...@li... > > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel > > > > ------------------------------------------------------------------------ ------ > > Enter the BlackBerry Developer Challenge > > This is your chance to win up to $100,000 in prizes! For a limited > > time, vendors submitting new applications to BlackBerry App World(TM) > > will have the opportunity to enter the BlackBerry Developer > > Challenge. See full prize details at: http://p.sf.net/sfu/blackberry > > _______________________________________________ > > dbus-cplusplus-devel mailing list > > dbu...@li... > > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel > > ------------------------------------------------------------------------ ------ > > Enter the BlackBerry Developer Challenge > > This is your chance to win up to $100,000 in prizes! For a limited > > time, vendors submitting new applications to BlackBerry App World(TM) > > will have the opportunity to enter the BlackBerry Developer > > Challenge. See full prize details at: http://p.sf.net/sfu/Challenge > > _______________________________________________ > > dbus-cplusplus-devel mailing list > > dbu...@li... > > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel > > > > ------------------------------------------------------------------------ ------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > dbus-cplusplus-devel mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel |
|
From: Randell J. <rj...@wg...> - 2009-10-27 19:38:01
|
>In the past week I worked on the echo example and tried to figure out
>why it did not work.
>
>It occurred to me that the multi threading cannot work since libdbus
>does a poll and dbus-cplusplus does a poll as well on the same file
>descriptor which cannot be safe.
>
>My echo-client blocked for 25 secs after a client issued a Hello
>request. The server's response let the dispatcher return from the poll
>call. The following watch_ready read the message from the socket but had
>it not ready to dispatch before the client issued its blocking poll.
>Then the response was ready but the client could not be woken up.
>
>My first idea was that we must somehow be able to wake up the client,
>then I realized that this code was located in libdbus. The second idea
>was to have a separate connection for each server and client object.
>
>To ensure that the dispatcher is not polling the client connections and
>accidentally receive responses an additional dummy dispatcher must be
>created and set as default_dispatcher while creating the client
>connections.
>
>Please have a look at my patch.
>It fixed the echo example for me.
The patch didn't seem to be attached - where can it be found? Can you
send it directly for me to try?
I've noticed problems before with 25-second delays when starting up a
dbus-c++ server in response to a dbus method.
Following is what I wrote on Sep 17th. From what you're saying, the
problem may not be caused by a timing hole, and there's no retry -
what's probably happening is a following watch-ready is kicking things
off.
I worked around the problem (painfully) by waiting for a signal from the
service before sending it a method.
Randell
From: Randell Jesup <rj...@wg...>
Subject: Problem with waiting for a service to be available
To: db...@li...
Date: Thu, 17 Sep 2009 17:09:31 -0400
There seems to be a designed-in timing hole in the DBus architecture, or
perhaps it isn't obvious (or explained) how you're supposed to wait for
a service to be available. Note that "ServiceName" is using dbus-c++
(the working "git" tree branch with ecore integration). Perhaps even
it's a dbus-c++ issue, though it doesn't seem like it.
If (like Qt's wrapper does to update ::isValid()) your application
watches for NameOwnerChanged to know when a destination is available to
send methods to, the ordering of operations leaves a timing hole. To
whit:
(From what dbus-monitor sees, what my Qt apps sees, and what another
application would probably see):
:1.17 sends AddMatch to DBus for NameOwnerChanged signal
Assumes: we've connected NameOwnerChanged signal to internal Qt slot
Time goes by, and then we start up the server for ServiceName
signal NameOwnerChanged for :1.35
:1.35 sends Hello to DBus
signal NameOwnerChanged for ServiceName
:1.35 sends RequestName to DBus for ServiceName
At this point, the listener notices NameOwnerChanged, and sends a method
(init()) to to ServiceName. Note that it may do this as soon as
NameOwnerChanged for ServiceName is delivered to :1.17
:1.17 sends init to Servicename
:1.35 sends AddMatch to DBus for ServiceName
Wait around 15-30 seconds....
:1.35 finally acts like it got method init() (and I think sends a reply,
which dbus isn't configured to let dbus-monitor see)
:1.17 sends version to ServiceName
Note that if ServiceName is already registered before :1.17 starts up,
there are no unusual delays.
Simplified profile (sorry, I didn't have the initial signal of
NameOwnerChanged for :1.35 in here)
mc 1253210449 162033 1 :1.35 /org/freedesktop/DBus org.freedesktop.DBus Hello
sig 1253210449 204469 10 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged
mc 1253210449 204727 2 :1.35 /org/freedesktop/DBus org.freedesktop.DBus RequestName
mc 1253210449 223718 52 :1.17 /com/foo/ServiceName com.foo.ServiceName init
mc 1253210449 250102 3 :1.35 /org/freedesktop/DBus org.freedesktop.DBus AddMatch
mc 1253210474 268186 53 :1.17 /com/foo/ServiceName com.foo.ServiceName version
mc 1253210475 397637 54 :1.17 /com/foo/ServiceName com.foo.ServiceName command
So, I assume the delay is a retry within dbus to deliver the message
before giving up. Even if it's queued in dbus, why isn't it delivered
when :1.35 (ServiceName) does the AddMatch?
Also note: the previous owner of ServiceName had been killed, and
appropriate NameOwnerChanged had occurred. From another run:
sig 1253221607 797520 17 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged
mc 1253221607 797769 11 :1.44 /org/freedesktop/DBus org.freedesktop.DBus ReleaseName
sig 1253221607 867286 18 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged
The first NameOwnerChanged is for com.foo.ServiceName, the second is for :1.44
--
Randell Jesup, Worldgate (developers of the Ojo videophone)
rj...@wg...
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X