so I am working with an API that has an object that connects to another machine and dose some proprietary magic to get information and is used to change it. Lets call this object a scheduler. Now I can only have one of these objects in my application, however I have multiple threads that need access to this object. Can I "Share" this object between my threads with pyqt? If so how do I access it? If I have multiple threads trying to access it at the same time will the thread hang till it is able or will it fail out my app?
Related
I would like to use the web server library ESPAsyncWebServer to create an API on my ESP32. But I was wondering, since the web server most likely runs on the secondary processor, do I need to make accessing data thread safe? So that the main loop and the web server can both access the data?
Or are they actually running on the same thread an I don't need to worry about it?
Yes, you need to implement thread safe access to any shared data. Asynchronous processing means it runs in its own thread. See the documentation for clarification.
For a Mac application I'm using an external (C++) library that has build in memory management. A drawback of that memory manager is that memory needs to be deleted on the same thread as the new call.
Currently I'm using GCD to run code concurrently, but I run into the problem that objects of that library get allocated on various threads and I can't correctly delete them.
Is there a way to call the delete operator on the original thread that called new? I realise that GCD wants to abstract the underlying threads away from me, but otherwise I've to write a custom GCD-like implementation where I have full control over the threads.
I am a beginner of Linux programming and I am not sure if what I expect is feasible. I would appreciate if someone could give me some tips.
What I want to do is to develop a shared object (.so file), which could be used by multiple applications. If one of those applications calls an initialize function in the shared object, a new thread will be created to run an infinite loop to accept incoming events. This thread will keep running even after the initialize function return. Thus all applications could keep sending events to this thread for processing.
I wonder if this could be achieved? Any idea will be appreciated.
As has been noted in the comments, this cannot be done: you cannot directly invoke a function in another process. This is why RPC, IPC, web services etc. were invented.
I have found an application which requests process information using wmi queries (all threads and more info on each thread). I modified this application to determine the CPU usage per thread.
(if my application is called 'appy', then the threads are named 'appy/0', 'appy/1', ...)
My question: is there a way to easily identify these threads outside of an IDE or another debugging environment?
I know there is the NameThreadForDebugging method, but this isn't accessible outside the debugging environment.
Is there a way to assign your own thread id upon creating that thread?
Or is the only way to know who is who (the threads) by creating a dictionary and write that dictionary to a file so it is externally accessible.
Thanks in advance!
No, you cannot assign your own thread ID, the thread ID is assigned to a thread by the CreateThread function and cannot be changed during its lifetime. And as you said the only way to identify thread in the external application (not a debugger) is to share the thread identification with that application somehow.
However it's not necessary to share the information through a file, you can use a shared memory block for instance. It will be much more efficient than using files.
As the reference about thread ID you can take the remark by the GetCurrentThreadId function:
Until the thread terminates, the thread identifier uniquely identifies
the thread throughout the system.
HI
I have a control that accesses a database using proprietary datasets. The database is an old ISAM bases database.
The control uses a background thread to query the database using the proprietary datasets.
A form will have several of these controls on it, each using their own thread to access the data as they all need to load simultaneously.
The proprietary datasets handle concurrency by displaying a VCL TForm notifying the user that the table being opened is locked by another user and that the dataset is waiting for the lock to be released.
The form has a cancel button on it which lets the user cancel the lock wait.
The problem:
When using the proprietary datasets from within a thread, the application will crash, hang or give some error if the lock wait form it displayed. I suspect this is to do with the VCL not being thread safe.
I have solved the issue by synchronizing Dataset.Open however this holds up the main thread until the dataset.open returns, which can take a considerable amount of time depending on the complexity of the query.
I have displayed a modal progress bar which lets to user know that something it happening but I don't like this idea as the user will be sitting waiting for the progress bar to complete.
The proprietary dataset code is compiled into the main application, i.e. its not stored in a separate DLL. We are not allowed to change how the locking works or whether a form is displayed or not at this stage of the development process as we are too close to release.
Ideally I would like to have Dataset.open run in the controls thread as well instead of having the use the main thread, however this doesn't seem likely to work.
Can anyone else suggest a work around? please.
Fibers won't help you one bit, because they are in the Windows API solely to help ease porting old code that was written with cooperative multitasking in mind. Fibers are basically a form of co-routines, they all execute in the same process, have their own stack space, and the switching between them is controlled by the user code, not by the OS. That means that the switching between them can be made to occur only at times that are safe, so no synchronization issues. OTOH that means that only one fiber can be running within one thread at the same time, so using fibers with blocking code has the same characteristics as calling blocking code from within one thread - the application becomes unresponsive.
You could use fibers together with multiple threads, but that can be dangerous and doesn't bring any benefit over using threads alone.
I have used fibers successfully within VCL applications, but only for specific purposes. Forget about them if you want to deal with potentially blocking code.
As for your problem - you should make a control that is used for display purposes only, and which uses the standard inter-process communication mechanisms to exchange data with another process that accesses your database.
COM objects can run in out-of-process mode. May be in delphi it will be a bit easier to use them, then another IPC mechanisms.