I'm writting a Golang package to manage NFC tags on an embedded system.
The tag reader is based on a NXP chip and a library from NXP : https://github.com/NXPNFCLinux/linux_libnfc-nci/tree/NCI2.0_PN7160. NXP also provides an example to read tags with that library : https://github.com/NXPNFCLinux/linux_libnfc-nci_examples/blob/master/tag-read_example/main.c.
The example works as expected and I'm able to read tags' information.
My Golang package uses cgo to call the functions in that C library. To enable the NFC discovery mode the following sequence must be done (as in the example):
nfcManager_doInitialize()
nfcManager_registerTagCallback(...)
nfcManager_enableDiscovery(...)
My golang package is stuck in the function nfcManager_enableDiscovery(...). After some investigation I figured out that the function is blocked when waiting for an event coming from another thread (https://github.com/NXPNFCLinux/linux_libnfc-nci/blob/NCI2.0_PN7160/src/nxp_nci_hal_nfc/nci/jni/NativeNfcManager.cpp#L2461).
The code sNfaEnableDisablePollingEvent.wait() is waiting for a mutex to be notified. It is calling pthread_cond_wait.
I tried to use runtime.LockOSThread but it doesn't fix my issue. I have checked that all the C functions called from my Go package have their paremters set with the right values, and it is the case.
Any idea on how to fix it ?
Related
I am currently experimenting with making a debugging interface to a Micropython implementation running on a NIOS2 processor. It is a very rudimentary way of during it by only sending and receiving register write or read commands to/from the device over ethernet.
However, I've got the bright idea that it could be nice if I, with a decorator, could set a whole function to be executed on the device. By sending the entire source code to the device and then uses exec().
This works just fine.
But I ran into the problem with function arguments. If the argument is an already created object how do I get this data to the device? Pickle does not exist in the version of Micropython I'm stuck at using.
I've found that getting the __dict__ information is the way to go. I am though stuck at how to create an object in micropython without running its __init__() method.
IE the object must not be initialized twice since it will corrupt itself.
Is this possible to do?
Regards
This is what says on http://invisible-island.net/ncurses/ncurses.faq.html#multithread
If you have a program which uses curses in more than one thread, you will almost certainly see odd behavior. That is because curses relies upon static variables for both input and output. Using one thread for input and other(s) for output cannot solve the problem, nor can extra screen updates help. This FAQ is not a tutorial on threaded programming.
Specifically, it mentions it is not safe even if input and output are done on separate threads. Would it be safe if we further use a mutex for the whole ncurses library so that at most one thread can be calling any ncurses function at a time? If not, what would be other cheap workarounds to use ncurses safely in multi-thread application?
I'm asking this question because I notice a real application often has its own event loop but relies on ncurses getch function to get keyboard input. But if the main thread is block waiting in its own event loop, then it has no chance to call getch. A seemingly applicable solution is to call getch in a different thread, which hasn't caused me a problem yet, but as what says above is actually not safe, and was verified by another user here. So I'm wondering what is the best way to merge getch into an application's own event loop.
I'm considering making getch non-blocking and waking up the main thread regularly (every 10-100 ms) to check if there is something to read. But this adds an additional delay between key events and makes the application less responsive. Also, I'm not sure if that would cause any problems with some ncurses internal delay such as ESCDELAY.
Another solution I'm considering is to poll stdin directly. But I guess ncurses should also be doing something like that and reading the same stream from two different places looks bad.
The text also mentions the "ncursest" or "ncursestw" libraries, but they seem to be less available, for example, if you are using a different language binding of curses. It would be great if there is a viable solution with the standard ncurses library.
Without the thread-support, you're out of luck for using curses functions in more than one thread. That's because most of the curses calls use static or global data. The getch function for instance calls refresh which can update the whole screen—using the global pointers curscr and stdscr. The difference in the thread-support configuration is that global values are converted to functions and mutex's added.
If you want to read stdin from a different thread and run curses in one thread, you probably can make that work by checking the file descriptor (i.e., 0) for pending activity and alerting the thread which runs curses to tell it to read data.
I know that LD_PRELOAD can be used to intercept calls to functions in shared libraries (if the app is not statically linked). However, I do not know how it can be used to add additional features or background threads to applications.
For example, I think Berkeley labs checkpoint/restart uses this method to add a background thread to an application that may be checkpointed later on.
So, now the question is how can a thread be injected into a compiled app using LD_PRELOAD without knowing before hand what functions of shared libraries are being called from this app?
It's a simple enough matter - you can implement the _init function - that would be void _init(void) {}, and you can use pthread_create in it (assuming you linked your library with -lpthread). You should compile your library with the other -l dependencies you need. GCC will allow you to replace the hardcoded _init() with another entry point, specified with an __attribute (constructor), as well. At any rate, your entry point will get called by LD.
When your library is injected, it gets injected before all others, but its own dependencies do get resolved as well, so whatever calls you make are generally ok (one notable exception being if you intercept functions you later call, for which you'll need to use the dlfcn APIs to do so safely).
I am trying to communicate with an arduino using the code from,
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
which uses termios to open and talk to an arduino in a non blocking way which works fine. What I was wondering is when on Java using rxtx I can register a callback function that is called when ever there is data on the line so that I don't have to manually check. I googled but could not find any info on how to register a callback function?
I am on Linux/OS X and I am trying to avoid launching a new thread just to watch/read data on the line.
Posix itself does not define a way to assign a callback function to be called when serial data arrives. The standard way to do this type of processing if you don't want to use a seperate thread is to use the select library function. This allows you program to define a set of file descriptors your program is interested in and then go to sleep. Select will automatically wake up your process if something interesting happens to one of the file descriptors you've declared interest in (such as new data becoming available for reading). This avoids having to busy-wait and poll multiple descriptors for activity.
Another option would be to use a library like libevent which sits on top of the Posix layer and provides the callback infrastructure. http://monkey.org/~provos/libevent/
Boost.Asio can provide callback functionality when using serial ports. It runs on Linux and Mac OS X.
OK, so I am writing an app, which plays music with the pyGST bindings.
This requires the use of threads to handle playback. The bindings library handles most of the thread control for me, which is nice(and what I was looking for in them).
Now, I don't have a full grasp on this concept, so I would be eager for some references. But the way I understand it, is I have to basically inform the app that it can use multiple threads.
I gathered this from the examples on the gstreamer site, where they use this call:
gtk.gdk.threads_init()
gtk.main()
according to here, this tells the app it can use multiple threads(more or less), which is where my above assumption came from.
That is the background. Now get this. I have placed those lines in my code, and they work fine. My app plays music rather than crashing whenever it tries. But something doesn't feel right.
In the examples that I got those lines from, they use gtk for the whole GUI, but I want to use wxWidgets, so it feels wrong calling this gtk function to do this.
Is there a wx equivalent to this? or is it ok to use this, and will it still work cross platform?
Also, I have to figure out how to kill all these threads on exit(which it does not do right now) I see how they do it in the example using a gtk method again, so again, looking for a wx equivalent.
PS: I think this(or the solution) may be related to the wx.App.MainLoop() function, but I am lost in trying to understand how this loop works, so again, good references about this would be appreciated, but I suppose not necessary as long as I have a good solution.
Try using this instead:
import gobject
gobject.threads_init()
I wonder how come it is not written in large print at the start of every python gstreamer plugin piece of documentation: it only took me several hours to find it.
A bit more details here.
I have no experience with pyGST, but the general advice for using threads and wxPython is to only update the GUI from the main thread (i.e. the thread that starts the MainLoop). See http://wiki.wxpython.org/LongRunningTasks for more information.
I have no experience with the python bindings, but I have had success using wxWidgets and GStreamer together on Windows. The problem is that wxWidgets runs a Windows event loop while GStreamer uses a GLib event loop. If you don't care about any of the GStreamer events, you shouldn't need to do anything. However, if you care to receive any of the GStreamer events, you will have to run your own GLib event loop (GMainLoop) in a separate thread with a separate GMainContext. Use gst_bus_create_watch to create a GST event source, add a callback to the source with g_source_set_callback, and then attach it to the main context of your GLib event loop with g_source_attach. You can then handle the GST in the callback, for example, to forward the events to the wx main event loop.