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.
Related
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 write a Python app that supports Linux and Windows, and I have a file object (that has a fileno() method returning a file descriptor), and I need to wait for IO completion on it.
In this particular case it's database connection (Postgresql), and I need to process notifications without a load on CPU (like it is described here).
On Linux it's quite simple:
select.select([fd], [], [])
But I would like to be able to do something like that on Windows too, and I'm struggling to find the correct way to achieve it.
It looks like WaitForSingleObject function could be handy, but as far as I understand it does not accept file descriptors.
How could this possibly be resolved?
I'm mainly posting this as I'm not sure if the multiprocessing lib is available for python 3x and if that's not the case, I need something that will allow one python script to send data as cleanly and efficiently as possible to another. They are separate so I cannot call one of them using import.
To explain it more in detail, I have to bots running with the discord.py library and so I cannot run one under the other using a function or class, but I want to pass data between them that way they can communicate without having to write into a file or enter a submission in chat.
What you are looking for is called interprocess communication.
They are gathered together at https://docs.python.org/3/library/ipc.html - you can dig depper into module signal or mmap - which is using memory mapped files which you excluded by choice.
I only ever worked with named pipes - both programs use the same name and communicate over a named pipe:
FIFOs are pipes that can be accessed like regular files. FIFOs exist until they are deleted (for example with os.unlink()). Generally, FIFOs are used as rendezvous between “client” and “server” type processes: the server opens the FIFO for reading, and the client opens it for writing. Note that mkfifo() doesn’t open the FIFO — it just creates the rendezvous point.
Availability: Unix.
(cited from above link)
For windows use: win32pipe, win32file and win32api - see Windows named pipes in practice)
An unix example can be found in this answer to that question: Python read named PIPE
I am writing a Lua script that uses a library to access a hardware device with buttons. I register a callback function to handle the button presses. The code looks like:
globalvar = {}
function buttonCallback(buttonId)
...accessing globalvar
end
device.RegisterButtonCallback("buttonCallback")
while true do
end
This works.
Now I want to update the globalvar not only at a button presses but also at 1 minute intervals. Since I will need to access a network resource anyway I plan on using the socket.select call to get the 1 minute interval.
#require "socket"
globalvar = {}
function buttonCallback(buttonId)
...access globalvar
end
device.RegisterButtonCallback("buttonCallback")
while true do
socket.select(nil, nil, 60) -- wait 60 seconds
...access network
...access globalvar
end
Now I am concerned about the concurrent access of the globalvar. How can I prevent race conditions here? Most sources on multithreading in Lua advise to use continuations in cooperative scheduling but I don't see how that could be applied in my case.
Assuming the library you're using is creating another thread behind the scenes, and your only concern is about accessing globalvar from within the callback, you could avoid it by writing to a pipe in the callback, and reading from it in your select loop. In other words, use a standard POSIX-style pipe to communicate the callback back to the main thread. This is a fairly common technique when dealing with e.g. POSIX signals.
Lua is not thread-safe within a particular lua_State instance. You cannot modify a global variable from one thread while another thread is doing something else with that Lua instance. You most certainly cannot be executing two separate scripts on the same instance.
Thread safety is something you have to do outside of Lua. You cannot have the C/C++ thread that detects the button press actually call Lua code directly. It must send that data to the main thread via some thread-safe mechanism, where it will call the Lua script for them.
So I took a deep dive into the Lua books and online documentation, and contacted the author of the device driver. As the answers already indicated, it takes much more than anticipated to handle the button callbacks safely.
My approach now is to write the device driver myself and use sockets as communication channel between the device and the Lua script.
My initial approach was to use continuations as this is advocated as the Lua "replacement" for multithreading but when I read the programming in Lua book, it turns out that in order to prevent busy waits, it uses the socket.select (!). This increased my feeling that a socket-based approach is good, especially since I also need sockets for internet access in my script.
I would like to implement a socket-like object in user space. There's an important requirement that it should be pollable (i.e. it's state should be queryable via select or poll call).
Is there a platform neutral way of implementing such an object?
I'm aware that on Linux there's eventfd which kind of suits the needs except that there's no way to force it to signalize neither POLLIN nor POLLOUT.
You can use socketpair() to create a pair of connected AF_UNIX sockets. This is better than pipe() as it allows for bidirectional communication. If this isn't good enough for your needs, another option (which requires root for a daemon) would be to use the as-yet-not-in-mainline-Linux CUSE patches to create a device driver in userspace to do whatever you like. Or you can just hook into whatever event loop your user will be using...
The new linux eventfd can also emulate POLLIN/POLLOUT, although not both at once - set its value to 0xfffffffffffffffe for POLLIN but not POLLOUT, 0 for POLLOUT but not POLLIN, or anything else for both.
Other than these options, there's no platform-neutral way to do this, no. The usual pattern is to use a FIFO just to wake up the event loop, and have it poll using some other API once it's awake.
You want to build an user space object, that will be accessible through system call ?
ie open, read, write etc ... are redirected to your userspace object ?
You need either kernel support or libc support, otherwise I don't see how you can redirect your system call.
eventfd is not what you are asking for, it is implemented in kernel space. Did you describe your real problem ? Could fifo or unix domain socket fit your need ?
What about pseudo tty ? I don't know if you can block writing from the master side by faking the hardware flow control.
It's really not clear what you're trying to do; if you want a socket-like device, why not use sockets? You don't say ... And what's the deal with POLLIN and POLLOUT?
I kinda suspect you might be interested in using pseudo-terminal devices, see man 7 pty.
Use pipe(). It gives you two fd's, one to write, one to read.
Use the fd[1] to do your select/poll on.
Use the fd[0] to signal your select/poll for activity.