I am writing an application that does multiple socket operations fairly consistently, and have a event messaging system similar to the javascript paradigm ( eventlistener.on(, ) / eventlistener.emit( ) ). I output some debug information from inside an async call that appends a TextBlock xaml element with the debugging information. When i emit the same event outside an async function, it works fine. I have wrapped my event on/emit calls with mutexes, which I assumed would be good enough to allow me to write to the TextBlock.
To visualize the event process:
[class]->listener->emit(< type>,< data>)->[Dispatcher]->[Listeners(< type>)]->lambda([class],< data>)
I'm not familiar enough with WinRT's async functions and the Windows 8 UI/Metro/Modern ideologies to know if there is a special way for me to append the TextBlock from a thread, or if there is a better way to go about this.
In short, is it possible to append a Textblock from an async function, and if so, do i need to do anything special?
There should be nothing preventing you from updating a TextBlock from an async function as long as the update is on the UI/dispatcher thread. The async function calls on a specific thread usually end on the same thread.
Related
Back to stackoverflow with another question after hours of trying on my own haha.
Thank you all for reading this and helping in advance.
Please note the console program has following functionalities:
connect to a frame grabber
apply some configs
store the incoming data (640 * 480 16-bit grayscale imgs) in a stream of buffers inside a while loop
Exits the while loop upon a key press.
disconnect from device
And I'm only adding the displaying the images functionality on the MFC GUI app. In short,
i) Converting a console app to an MFC app (dialog based)
ii) decided to use thread for displaying images, but DK how to properly exit from thread when there are certain tasks to be done (such as call disconnectFromDevice(); freeBuffers();, etc) before exiting the thread.
iii) have tried making the while loop condition false but didn't work
( I actually want this to be a callback function that's called repeatedly but IDK how to implement it inside a thread)
iv) forcing AfxEndThread didn't work and it's not even the way it should be done (I think).
So my question is,
1. Are you supposed to use a while loop to excuete a certain job that should repeatedly be done? If not, do you have to implement a callback inside a thread? Or use Windows message loop? Why and how? Please provide a hello-world-like sample code example
(for example, you are printing "hello world" repeatedly inside a thread with a condtion in an MFC GUI app. How do you update or check the condition to end the thread if you can't just AfxEndThread() inside the threadproc)
2. If it's ok with a while, how do you exit from the while loop, in other words how do you properly update the exit condition outside the thread the while loop's in?
Please refer to the source code in the provided link
ctrl+F OnBnClickedConnectButton, AcquireImages and OnBnClickedDisconnectButton
https://github.com/MetaCortex728/img_processing/blob/main/IR140Dlg.cpp
Worker threads do not have message-queues, the (typically one and only) UI one does. The message-queue for a thread is created by the first call of the GetMessage() function. Why use messages to control processing in a worker thread? You would have to establish a special protocol for this, defining custom messages and posting them to the queue.
Worker threads can be implemented as a loop. The loop can be terminated based on various conditions, like failures to retrieve any data or request from the user. You can simply exit the thread proc to terminate the thread's execution. If the thread doesn't respond it may have stuck (unless it performs a really lengthy operation) and the UI thread must provide some mechanism to kill it. That is first request termination and if it doesn't respond within some set time then kill it.
The condition mechanism to terminate should best be some synchronization object (I would recommend a manual-reset event), interlocked variable or a simple boolean which you should access and set using a critical section.
Some considerations:
You pass a parameter block to the thread. Make sure that it remains alive throughout the thread's lifetime. For example, it should NOT be a local variable in a function that exits before the thread's termination.
The loop must be "efficient", ie do not loop infinitely if data are not available. Consider using blocking functions with timeouts, if available.
Resource management (eg connecting/disconnecting, allocating/releasing etc) should best be performed by the same thread.
An alternative implementation can be APCs. Then the thread's proc function is a while(!bTerminate) { SleepEx(INFINITE, TRUE); } loop, and other threads issue requests using a the QueueUserAPC() function.
The AfxEndThread(0) call in OnBnClickedDisconnectButton() is wrong, it terminates the current thread, which in this case is the main (UI) thread. Check the documentation.
A sidenote, my suggestion about the project type is not a dialog-based application but instead a normal MFC application without a document class (uncheck the Document/View architecture support option), as it offers features like menus, toolbars and the like, and most importantly the ON_UPDATE_COMMAND_UI handlers.
how can i receive RS232C data by callback func?
i know there is many another way to solve ploblem.
ex)
using poll, select(), while(1){ read.... } ....
check event(WaitingOnRead, WaitCommEvent(), SetCommMask Function .. etc..)
but.
they all use thread or synchronous way.
i want
1. don't use thread
2. Asynchronous way
like
device(RS232C)---->COM // data receive event occur!!
-> callback func call // user func like save or printf receive data)
-> run user func
possible?
plz help me...
ps.
https://msdn.microsoft.com/en-us/library/system.io.ports.serialport.datareceived(v=vs.110).aspx
i don't need .NET Framework solution.
need WIN32 MFC way...
It has been awhile since this question was posted, so you may have already reached a solution. However if, as i understand your question, you want to read from a serial port asynchronously (ie non blocking) then you have to use threads.
One thread to read the data from the Serial Port, when it arrives, flag that 'Data Available', either by executing a pre-defined piece of code, or preferably by firing a 'Data Available' event. This thread then sleeps until another piece of data arrives.
A second thread then consumes the data, to do whatever you need, but without separate threads you are, by definition, working synchronously.
Using libev you can setpu callbacks to be triggered when data is available on the serial port. Reading and uderstanding of the usage of libev can help.
https://linux.die.net/man/3/ev
In my C++ application I'm using a third party library for Bluetooth discovering process. I'm looking at the examples provided to learn how to use it.
The example that best match my needs is a simple GUI application that call a Discovery(long timeout) function from the library to start the Bluetooth discovery.
That function returns immediatly (so that the GUI is not freezed) and fires an __event called OnDeviceFound once a new BT device has been discovered and OnDiscoveryComplete once the timeout has elapsed.
So in the GUI constructor (of the example) there're __hook defined like this:
__hook(&BluetoothDiscovery::OnDiscoveryComplete, &m_Discovery, &BluetoothClientDlg::OnDiscoveryComplete);
Now, I need to implement the same in my application, that is not a Window application but a console application that runs as a Windows Service, doing a continuos discovering on a separate thread looking for new devices.
So, actually, since my implementation makes use of a thread for discovery, I don't need an event based discovery procedure, but I need a blocking discovering. The library does not provide a blocking API for discovering.
So here comes the question: is it possible to use an event based function in a blocking function? In other words, is it possible to write a function that could be called in the thread main loop every n seconds that does a discovery procedure and return the founded Bluetooth devices (using that event-based library API)?
What you want is a Semaphore which your main thread sits on until the discovery thread completes and then notifies your main thread to wake.
Active waits like what you suggest are nasty, and should be avoided where you can.
I have an application that creates two threads. (thread_1 for a Qt GUI and thread_2 for an app that runs a TCL interpreter).
I want thread_1 (Qt GUI) to create a command and send it to thread_2 (TCL interpreter).
I'm thinking of connecting thread_1's stdout to thread_2's stdin, and I don't know how to do it ?
if you know how to do it or can suggest different way of work, I'd appreciate your help.
The solution I propose requires to set up 2 std::queue<> or std::list to let each thread pass a message to the other one and vice versa. The simplest way is to have each thread setup its own incoming message queue, and let other threads get a pointer to it. First you need a synchronized version of the queue datatype: as I gave in the comment, there's an implementation there.
Then you only need to upgrade your thread class (or runnable class, or whatever you're using as an abstraction of a task) with one such queue available internally, and a send method publicly accessible so that other tasks may post a message to it. Your task will then have to periodically check that queue for incoming message, and eventually process it.
NB: I got that page from stack overflow itself, since the blog owner is a member of this community. See that page talking about queue synchronization issue.
I am not sure why you would like to go through standard input and output here, but I think the issue might be much simpler than you think. I would just personally use the qt signal-slot mechanism as follows:
connect(guiThreadSender, SIGNAL(sendCommand(const QByteArray&)),
tclThreadReceiver, SLOT(handleCommand(const QByteArray&)));
I wonder if anyone familiar with a synchronization mechanism in user-mode, by which an app can register a "callback" function that would be called when another app signals it ... i don't mind the callback to be in an arbitraty thread.
Suppose i'm having lots of "Worker" processes in parallel, And one wants to notify them of a change (no payloaded data needed), by which every process will have to do some internal updates.
The immediate approach to this was to create another thread in each of them, and have an infinite loop that waits for a global event and call the callback function right afterwards. To signal this, one process would only need to signal this global event.
The problem is that i'll have lots of parallel processes in this project, i don't want to add thread*nProcesses to the system just to implement this, even if they're mostly paused.
The current "workaround" i found for this would be to hold my own "dummy" registry key, and every process will "register registery notification callback", when one app wants to notify the others it will just trigger a write to this key... and windows will callback every process which registered to this notification.
Any other ideas?
The nicer solution, which doesn't pollute the registry, would be to use a shared pipe. All workers can connect to the named pipe server, and do an async read. When the server wants to kick the workers, it just writes a byte. This triggers the completion routine of the worker. Basic example
Still, this notification has the same drawback as most other Windows notifications. If all of your worker threads are running worker code, there's no thread on which your notification can arrive - and you didn't create a special thread for that purpose either. The only solution around that is CreateRemoteThread, but that's a very big hammer.
thank you all for the useful ideas,
Eventually, I accidentally came across RegisterWaitForSingleObject which seems to do just that.
I'm still taking in account #MSalters comment about not having enough free worker threads at a given time since i'm assuming this callback mechanism relies on the same callback mechanism most Win32API does