How to make X11 application to listen to DBus signal.
That to listen to Dbus signal gmainloop should be launched, and for X11 app XEvent loop.
So is there an elegant way to do this ? Or do I have to run gmainloop in another thread.
Regards,
Levon
If you want to block on two or more things (say X and dbus) you need a main loop.
You could use GLib's main loop or libev or other libraries.
Here are two examples of using Xlib with GLib's main loop:
http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkeventsource.c
http://git.gnome.org/browse/metacity/tree/src/core/eventqueue.c
Shouldn't you be able to get a file descriptor for the X event loop? Then you should be able to add it to the gobject mainloop.
From what I can see, ConnectionNumber(xdpy) will give the file
descriptor, which you can then add to a source, which you can use with
g_source_add_poll().
Related
I am writing a new syscall where I want to send a kill(pid, SIGSTOP) signal to a process that I just created in order to move it from the runqueue to the waitqueue. Then, I can wake it up again using kill(pid, SIGCONT).
The problem is that the kill is only used from the userspace, how can I send a signal from inside the kernel itself? is there an equivalent function to use that can do so?
I found kill_pid, but I don't know how its headers should be included.
It seems like you found the correct method of sending a signal to a process from kernel space - kill_pid which is also exported, which means it is available to kernel modules.
Using elixir - lets look at some usage examples - this shows you in which header file the symbol is defined - so you should start by including sched/signal.h and do the process for any other dependencies you may have
I'm in the very unfortunate position of needing to interface nodejs's libuv and GLib's MainLoop on all three major OSes. I need to interleave both libuv's main loop and GLib's maing loop so that both parts of the project can be happy and live together. On unixes, that's easy enough because libuv returns a file descriptor to poll on:
GSource source;
// ...
g_source_add_unix_fd (&source->source,
uv_backend_fd (loop),
(GIOCondition) (G_IO_IN | G_IO_OUT | G_IO_ERR));
On Windows however, there isn't a file descriptor to poll on. What is available is a IO Completion Port HANDLE, under uv's loop->iocp. I'm not exactly sure how to proceed from here. I was thinking that I should probably be using the following function from GLIB:
void
g_source_add_poll (GSource *source,
GPollFD *fd);
But then I'd need to create a GPollFD from that and I'm not sure how to do it or if it's the right option. Any hint that could help me progress is welcome.
Relevant link: https://github.com/romgrk/node-gtk/blob/master/src/loop.cc#L68-L75
when use pthread (or QThread with moveThread function) to read data (with mutex) GUI slows.
Why?
GUI Thread and pthread worker (or Qthread) are two different thread right?
Precise that the GUI don't read/write anything of data, so they are two process not correlated.
Why this issue?
(Above example of pthred worker, while GUI Dialog is created simple with qt Creator and live in main thread)
void* task_camera_notifier(void*)
{
while(AppState::is_left_camera_in_grabbing && AppState::is_right_camera_in_grabbing)
{
camera_data left_data;
SharedData::SecureAccess_get_leftCameraFrame(left_data);
}
return NULL;
}
SharedData::SecureAccess_get_leftCameraFrame(left_data); seems a very heavy operation to me (possibly it needs to read in the image from the camera which can be pretty big, then copy it in the object). And then right after the data is just read in, the left_data goes out of scope and the image is deleted. And then again, and again. Try to include a small sleep in this while loop so that it does not eat up all system resources.
Final goal: What are you trying to achieve?
I am trying to close a mutex that is being held by a process on Windows using Win32 functions. This can be done using procexp but I need to do it programmatically without using the procexp GUI.
Method1:
I tried injecting a dll into the processs using EasyHook and then tried the following from the injected thread:
- OpenMutex
- ReleaseMutex
It gave me the ERROR_NOT_OWNER error probably because the release was called on a different thread than the one that called AcquireMutex.
Method2:
After injecting the dll, I tried to hook for CreateMutex using mHook. The hooked CreateMutex just called back the original CreateMutex. But this would just crash the application.
I can use procexp to close the mutex but I need to do it programmatically. How does procexp do it? How can it be done programmatically without any kernel mode code?
Use NtQuerySystemInformation() to retrieve an array of open handles, loop through the array until you find the desired mutex handle in the target process, then close it using DuplicateHandle() by specifying the DUPLICATE_CLOSE_SOURCE flag.
The following article explains it in more detail:
HOWTO: Enumerate handles
Just adding a complete answer. I had to add the following the following code to handles.cpp after the mutex is recognized:
HANDLE realHandle;
ret = DuplicateHandle(processHandle, (HANDLE)handle.Handle, GetCurrentProcess(), &realHandle, 0, TRUE, DUPLICATE_CLOSE_SOURCE);
if(!ret)
printf("DuplicateHandle Problem!");
if (!CloseHandle(realHandle))
{
printf("Problem closing the copied handle");
}
printf("", realHandle);
}
I desire to construct a Hexapod which utilizes Arduino and is remotely controlled via Bluetooth, at present I am writing the code for its walking(in Arduino part),however I do not know how to proceed.The problem is as follow:
When a new command is received from the remote device I want the legs to stop what they are doing and carry out the received command.If this action is realized with Interrupts then after the command has been completed the previous process again starts,which is undesired for me. What can be done?
Thanks in advance for your answers.
The arduino doesn't really have separate processes - or even an OS.
You should think in terms of "states". Have a global (sorry) int representing the current state (use an enum) then when you do a new command set the state to the new command and return, then have a main loop which checks the state and performs whatever function is needed.