I am creating an console application on a raspberry pi in lazarus. This console applications spawns a thread that reads a sensor. I am looking for a way to pass data in a thread safe way from the thread to the main application.
Currently I am using postmessage to send data from the thread to the main application. I have tested this with a GUI and that works fine. When I tried to implement this to an console application I came to the conclusion that an handle is connected to a window.
So the question is: How can I pass data asynchronously from a thread. Can I use postmessage and create an handle for the console application or is there a different thread safe way to pass on data.
Related
I have a program that uses ZMQ to send and receive between a C++ application and a Python GUI. The Python sends all commands to the C++ app to do the work, the C++ app periodically sends back status to update the GUI.
The C++ is multi-theaded but we never made the call zmq_send thread safe, so in 1 out of 100,000 runs we'd get an unhandled exception or segmentation fault if two threads tried to send status back to the gui simultaneously. This took longer than I care to admit figuring out since it was so sporadic. This was easily solved with a mutex around zmq_send because the socket is managed by a singleton.
In addition to the processing threads, there is one thread that just idly waits to receive and dispatch commands from the gui using zmq_poll and then zmq_msg_recv when something is available.
The question, can I safely poll the same socket while a send is happening? Most of the time the receive thread is sitting in zmq_poll with a timeout, and sends seem to be happening without issue. I can't seem to find any good documentation about this. I assume a mutex needs to protect zmq_send and zmq_msg_recv from occurring simultaneously, but I am not sure about the safety of polling while sending.
Details about the setup: using PAIR interface with a single client and server. All messages are small (<1KB). There is only one socket shared for sending and receiving.
This is a large, decade old application I'd like to avoid redesigning if possible.
I'm currently facing a problem in my game that I'm writing using Qt. I have this QTcpSocket to communicate with the game server, and some AI running in an other thread.
The problem is that when I want to send some data to the server from the AI thread, I get the following error:
QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
Is there a way to get around this issue?
Hello guys ive been searching for an answer to this question and was unable to find a suiting solution to my problem.
i have a chat program that has a somewhat advanced gui. The chat program in total consists of two programs a server and a client. ive created a protocol that my clients listens to and reacts depending on what type information it gets.
i have created a class called clientReciver which extends Thread. but i am now confused on how i will get the informaiton that the thread recives and use it in my gui.
and example of this could be how will i get the text that one of my clients sends and add it to my GUI?
It may be worth mentioning that i am using JavaFx Scenebuilder to build my GUI.
Hope someone is able to help be
Best Regards Marc Rasmussen
Hard to advise without details on your custom protocol. See the zenjava blog for some inspiration.
Use a Task to invoke your server from your client. If the result of the client server call is synchronous get the value returned by the call when the task completes. If the call is asynchronous or the server pushes data to the client, set up a listener on the client running in it's own thread and when it gets a result invoke Platform.runLater to feed the result to the JavaFX application thread for UI processing.
I have a Delphi 6 application that uses the ICS component suite to do socket communications. I have my own server socket VCL component that creates client TWSocket sockets when a new session becomes available. The client sockets I create do have the Multithreaded property set to TRUE, but all that does is changes the way the client socket handles socket messages to a manner that is safe from a background thread (non-main VCL thread). TWSocket does not spawn a thread to handle socket data traffic, which is what I need.
I need to have the receive calls occur off the main VCL thread, the main user interface thread, because the incoming data to the client socket is audio data that needs to be processed rapidly, in 50-100 milliseconds or less. In other words, one hiccup on the main VCL thread and the audio stream is disrupted. This is why I want to push the OnDataAvailable() event that fires whenever incoming data is available on to a high priority background thread. In other words, I want to force the message processing loop belonging to the client TWSocket object to a background thread.
I believe I can do this by creating the client socket via a background thread, but I'm hoping to avoid that since currently I use a VCL component I made that acts as a socket server. This is the entity that Accepts the incoming connection and spawns the client sockets. The socket server is created on the main VCL thread.
Therefore my question is, is there a (relatively) easy way to create the client sockets so they use an existing background thread to do their socket processing, especially the FD_RECV message handling? If not an existing background thread, then I will create one for each client socket I create, but I need to know how to make sure the new TWSocket object uses that background thread when it runs its message loop that processes socket messages, so how would I do that?
For other ICS/TWSocket users out there, the solution is in the ICS ThrdSrv demonstration project that comes with the package. Take a close look at that project, especially its use of the ThreadAttach() and ThreadDetach() methods. That sample project shows how to create client sockets that have message pumps that run in the context of a worker thread.
I have a simple application on a OpenWRT style router. It's written in C++ currently. The router (embedded Linux) has very limited disk space and RAM. For example there is not enough space to install Python.
So, I want to control this daemon app via the network. I have read some tutorials on creating sockets, and listening to the port for activity. But I haven't been able to integrate the flow into a C++ class. And I haven't been able to figure out how to decode the information received, or how to send a response.
All the tutorials I've read are dead ends, they show you how to make a server that basically just blocks until it receives something, and then returns a message when it got something.
Is there something a little more higher level that can be used for this sort of thing?
Sounds like what you are asking is "how do I build a simple network service that will accept requests from clients and do something in response?" There are a bunch of parts to this -- how do you build a service framework, how do you encode and decode the requests, how do you process the requests and how do you tie it all together?
It sounds like you're having problems with the first and last parts. There are two basic ways of organizing a simple service like this -- the thread approach and the event approach.
In the thread approach, you create a thread for each incoming connection. That thread reads the messages (requests) from that connection (file descriptor), processes them, and writes back responses. When a connection goes away, the thread exits. You have a main 'listening' thread that accepts incoming connections and creates new threads to handle each one.
In the event approach, each incoming request becomes an event. You then have event handlers that processes these events, sending back responses. Its important that the event handlers NOT block and complete promptly, otherwise the service may appear to lock up. Your program has a main event loop that waits for incoming events (generally blocking on a single poll or select call) and reads and dispatches each event as appropriate.
I installed python-mini package with opkg, which has socket and thread support.
Works like a charm on a WRT160NL with backfire/10.03.1.