connecting to a signal with qdbus - dbus

qdbus is rather straightforward when calling methods, but is it possible to connect to a signal with it? Signature:
signal void org.kde.kwin.Scripting.printError(QString text)

From #dbus on irc.freenode.org:
thiago | the command-line utility can only send calls
thiago | use dbus-monitor for that

Related

How can a Ruby C extension store a proc for later execution?

Goal: allow c extension to receive block/proc for delayed execution while retaining current execution context.
I have a method in c (exposed to ruby) that accepts a callback (via VALUE hash argument) or a block.
// For brevity, lets assume m_CBYO is setup to make a CBYO module available to ruby
extern VALUE m_CBYO;
VALUE CBYO_add_callback(VALUE callback)
{
if (rb_block_given_p()) {
callback = rb_block_proc();
}
if (NIL_P(callback)) {
rb_raise(rb_eArgError, "either a block or callback proc is required");
}
// method is called here to add the callback proc to rb_callbacks
}
rb_define_module_function(m_CBYO, "add_callback", CBYO_add_callback, 1);
I have a struct I'm using to store these with some extra data:
struct rb_callback
{
VALUE rb_cb;
unsigned long long lastcall;
struct rb_callback *next;
};
static struct rb_callback *rb_callbacks = NULL;
When it comes time (triggered by an epoll), I iterate over the callbacks and execute each callback:
rb_funcall(cb->rb_cb, rb_intern("call"), 0);
When this happens I am seeing that it successfully executes the ruby code in the callback, however, it is escaping the current execution context.
Example:
# From ruby including the above extension
CBYO.add_callback do
puts "Hey now."
end
loop do
puts "Waiting for signal..."
sleep 1
end
When a signal is received (via epoll) I will see the following:
$> Waiting for signal...
$> Waiting for signal...
$> Hey now.
$> // process hangs
$> // Another signal occurs
$> [BUG] vm_call_cfunc - cfp consistency error
Sometimes, I can get more than one signal to process before the bug surfaces again.
I found the answer while investigating a similar issue.
As it turns out, I too was trying to use native thread signals (with pthread_create) which are not supported with MRI.
TLDR; the Ruby VM is not currently (at the time of writing) thread safe. Check out this nice write-up on Ruby Threading for a better overall understanding of how to work within these confines.
You can use Ruby's native_thread_create(rb_thread_t *th) which will use pthread_create behind the scenes. There are some drawbacks that you can read about in the documentation above the method definition. You can then run the callback with Ruby's rb_thread_call_with_gvl method. Also, I haven't done it here, but it might be a good idea to create a wrapper method so you can use rb_protect to handle exceptions the callback may raise (otherwise they will be swallowed by the VM).
VALUE execute_callback(VALUE callback)
{
return rb_funcall(callback, rb_intern("call"), 0);
}
// execute the callback when the thread receives signal
rb_thread_call_with_gvl(execute_callback, data->callback);

org.bluez.MediaTransport1, member=Acquire returning org.freedesktop.DBus.Error.NoReply

While trying to call Acquire dbus api from our application , the bluez stack gets the fd, imtu, omtu successfully, and sends it over dbus using g_dbus_send_reply. But when we call dbus_connection_send_with_reply_and_block from our application, we are unable to get the reply,and unable to get the fd, imtu and omtu.The dbus is returning org.freedesktop.DBus.Error.NoReply.
dbus version used is 1.10.10.
Bluez version - 5.37
Dbus error seen is ,
method call time=1493814994.072004 sender=:1.50 -> destination=org.bluez serial=50 path=/org/bluez/hci0/dev_A4_70_D6_7A_74_7F/fd2; interface=org.bluez.MediaTransport1; member=Acquire
error time=1493814994.074396 sender=org.freedesktop.DBus -> destination=:1.50 error_name=org.freedesktop.DBus.Error.NoReply reply_serial=50
string "Message recipient disconnected from message bus without replying"
Bluetoothd error seen is,
State changed /org/bluez/hci0/dev_88_79_7E_84_2C_54/fd2: TRANSPORT_STATE_PENDING -> TRANSPORT_STATE_ACTIVE
bluetoothd[7523]: Disconnected from D-Bus. Exiting.
Any inputs will be of great help. Awaiting for the reply.
This issue is resolved by applying Smack patch for bluetooth.
This patch allows kernel sockets to be used by applications.
Patches are,
0001-Smack-File-receive-for-sockets.patch
0002-smack-fix-cache-of-access-labels.patch
0003-Smack-ignore-null-signal-in-smack_task_kill.patch
0004-Smack-Assign-smack_known_web-label-for-kernel-thread.patch
Gerrit link -
https://gerrit.automotivelinux.org/gerrit/#/c/6995/

anyway to avoid to loop monitor multi handle in libcurl?

I've read some examples from the libcurl homepage. It always uses loop monitoring the multi handle when download through curl_multi_perform like below:
curl_multi_add_handle(multi_handle, easy_handle);
do {
curl_multi_wait(…);
curl_multi_perform(multi_handle, &still_running);
} while (still_running);
that make me block on the section of program
I want the libcurl will do callback after the anyone of easy_handle is download finished
for example:
Server can receive requests and parse the requests to multi_handle to
download asynchronously.
Server still can receive requests while multi_handle is downloading.
Those are independent(asynchronous in other words)
Typically curl_multi_perform is called in a loop to complete all the curl related task, like http transaction.
The way you have put the code, you would not achieve the asynchronous way of using libcurl. There are ways to achieve it.
In a typical implementation you will have your main loop, where you might be dealing with number of task. For example
do
{
execute task1
execute task2
.............
execute taskn
}
while(condition)
In that loop, you can call curl_multi_perform.
So main loop looks like
do
{
execute task1
execute task2
.............
execute taskn
curl_multi_perform(curlm, &count);
}
while(condition)
That way you will do all your task and curl_multi_perform is called time to time and you will achieve asynchronous way of using libcurl.
Please check documentation, depending on some return value you may avoid calling curl_multi_perform (I remember reading it previously).

Performing the equivalent of chattr +i filename.txt from Linux application

Is there any interface in the Linux userspace API that will allow me to perform the action equivalent to
chattr +i myfile
chattr -i myfile
If possible I need to do this from within my application but I cannot find anything online that suggests how one would go about doing this from the Linux API. I would have thought there would be some kind of ioctl call available to do this but I simply cannot find any details about it.
have a look at:
http://www.danlj.org/lad/src/setflags.c.html
and if you do some strace on chattr, you could have found out that it calls stuff that looks like:
ioctl(fd, EXT2_IOC_SETFLAGS, flags)
(have a look at this thread)

what happens if an application open more than one connection to syslog?

I have an application that uses syslog for logging. another library within this application explicitly calls openlog() for its own usage, in this case something strange happens: stderr output is sent to a tcp socket I already opened.
When I change the lib's output log to stderr or stdout everything works fine.
I was wondering if this a problem with two syslog connection or is it just a mess-up somewhere in the code?
This is syslog initialisation of the main app:
openlog( "app", LOG_PID|LOG_NDELAY, LOG_LOCAL1 );
This is syslog initialisation of the lib:
openlog("lib", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_LOCAL1);
It is probably implementation dependent. If you use MUSL libc the code is here in syslog.c an you can see that only one fd is used for syslog (so two openlog-s are sharing the same log_fd). Look into GNU libc source code to see what happens on most Linux implementations. You might also investigate with strace or ltrace

Resources