hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/ | GSoC2018: https://wp.me/p4pxJf-k1
parsa has quit [Quit: Zzzzzzzzzzzz]
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving]
diehlpk has joined #ste||ar
parsa has joined #ste||ar
hkaiser has quit [Ping timeout: 265 seconds]
eschnett has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
K-ballo has quit [Quit: K-ballo]
eschnett has quit [Quit: eschnett]
<heller_>
ms[m]1: No, they didn't want to
jaafar has quit [Ping timeout: 265 seconds]
nikunj has joined #ste||ar
nikunj has quit [Quit: Leaving]
jakub_golinowski has joined #ste||ar
jakub_golinowski has quit [Ping timeout: 256 seconds]
david_pfander has quit [Ping timeout: 255 seconds]
<jakub_golinowski>
ms[m]1, ok the solution I mentioned yesterday with apply was working but I realized it was not fully reliable. Now I am using mutexes and wait conditions as in original MartyCam to synchronize between hpx task and main thread.
nikunj97 has quit [Quit: Page closed]
nikunj97 has joined #ste||ar
<ms[m]1>
jakub_golinowski: okay, so there's still something fishy there
<ms[m]1>
remember that using os mutexes in hpx threads is not a good idea
<jakub_golinowski>
ms[m]1, hmm
<jakub_golinowski>
ms[m]1, so how can this be done?
<jakub_golinowski>
ms[m]1, I switched to this because using futures on main_pool_executor was not behaving as expected
<jakub_golinowski>
and I have to somehow sync between the main thread and HPX tasks
<jakub_golinowski>
so should I go the other way and use HPX's syncing tools? But will they be available in the main thread?
<ms[m]1>
yeah, so the main thread you use as the "main qt thread"?
<ms[m]1>
no, that won't work either
<ms[m]1>
what information do you need to get from the main thread to an hpx thread or vice versa?
<jakub_golinowski>
ms[m]1, I have just commited the current version
<jakub_golinowski>
The main changes are to the CaptureThread (run, startCapture, stopCapture)
<jakub_golinowski>
My idea is to offload any direct HPX interactoin from MartyCam class and encapsulate it fully in CaptureThread and in a second in ProcessingThread
<jakub_golinowski>
And the information I want to pass is a "abort" flag that enforcest the thread to finish and I want to also wait in the main thread for that to happen
<ms[m]1>
so is it possible for you to create MartyCam from an hpx thread (practically somewhere in hpx_main), so that when you wait for the future you will be on an hpx thread? to set the abort flag you obviously don't need any synchronization
david_pfander has joined #ste||ar
<jakub_golinowski>
ms[m]1, MartyCam is the QT MainWindow so it needs to be run in the main thread
hkaiser has joined #ste||ar
<ms[m]1>
jakub_golinowski: hmm, so what you could do is something similar to (or the same as) run_as_hpx_thread
<ms[m]1>
notifying a condition variable from an hpx is thread is okay, waiting is bad (but allowed)
<jakub_golinowski>
ms[m]1, great because I am only notifying from hpx thread
<jakub_golinowski>
the wait is in the main thread
<ms[m]1>
you would then notify as the last thing in the capture/whatever thread
<ms[m]1>
waiting doesn't mean that the thread is completely gone, but you know at least that it's about to exit
<jakub_golinowski>
ms[m]1, but I am sure that after the wake call the thread will not execute any my lines of code and especially acessing the webcam which is a single resource
<ms[m]1>
yep, that you'll know
<jakub_golinowski>
and therefore as of now it seems like an acceptable solution
<jakub_golinowski>
ms[m]1, also when I sorted out the issues with starting and stopping the capture and processing threads the error that was earlier upon closing application is seems to be fixed. When the widnow is closed the tasks are closed via the set flat->wait notification mechanism and then the threads objects are deleted
K-ballo has joined #ste||ar
<ms[m]1>
jakub_golinowski: very good, what is flat->wait though?
<jakub_golinowski>
ms[m]1, ah -> was meant as "next step"
<jakub_golinowski>
and I made a typo
<jakub_golinowski>
so it is: (1) set flag abort such that the loop within hpx task will be exited and the task itself will reach the last statement which is wake_all (2) the main thread will be woken up due to the call in the last line of hpx task
jakub_golinowski has quit [Ping timeout: 265 seconds]
diehlpk has quit [Remote host closed the connection]