A function in a win32 process (call it void cCB()) calls a VB6 Sub (call it vb6S, which receives some numeric data type data from cCB. cCB originally received vb6S reference via AddressOf.
I've got two basic newbie questions about this:
Question 1: Is cCB's thread blocked by the call while vb6S() executes its code?
Question 2: Will VB have any "issues" if cCB's thread terminates and cCB's
memory is de-allocated before vb6S has completed its work?
EDIT:
In response to the request for code (and thanks for that downvote), here is the issue:
The task is a microsecond timer, to be used to unblock the WM queue of two VB IDE's when debugging two VB apps that are communicating via WM_COPYDATA messages.
That is: there are apps Alice and Bob. When Alice sends Bob a wm74 (WM_COPYDATA) message, Bob hooks on to it, saves the information in the copydatastruct, and then is finished with the message. The problem is that, now, in debugging, both Alice's and Bob's message queues are blocked as long is either debugger is at a break point. It doesn't take long to kill one or both IDE's at that point.
So what I want to implement is an old Java Applet trick: Bob calls out of process, which waits a tiny slice of time, and calls back in. While out of process, Bob can release the message, the app/IDE tells Windows the message is handled, and Alice can go about her business. To do this, before returning, Bob's message handler calls into a win32 DLL function, say:
typedef void (__stdcall *FUNCPTR)(int);
void __stdcall ExecuteCallback(FUNCPTR cbAddress, double microS){};
which Bob calls as
ExecuteCallback AddressOf My74Processor, 250
where My74Processor contains the app logic to process the string according to the cases in the code number that Alice put in the message structure.
ExecuteCallback grabs an existing timingWork code object from a queue of those, and puts it into a queue of threads via a workQueue manager that knows to start the thread at the proper point in the timingWork class.
After the timingWork timer clocks 250 microseconds (in this case) via watching QueryPerformanceCounter, it calls back to Bob's Sub at
Sub My74Processor(ByVal reason as Long)
and terminates. The timingWork object is not destroyed; the last thing it does is put itself back in the queue of available objects. The thread, on the other hand, terminates, and is available in the thread queue for more, maybe different, work when its turn comes around again.
Back with Bob, there is a breakpoint set in the processing code down in Sub My74Processor. My questions, then, are in this context:
(a) when that breakpoint is hit, and the programmer takes some time to check variables and logic, and then continues the process, will all be fine in Bob's IDE's stack after My74Processor ends?
(b) when the timingWork routine makes the call back, will that thread be blocked?
I'm virtually certain the answer to (b) is "no." I'm worried about, and not experienced enough with VB6 to know the answer to that.
EDIT2 #wqw, I came to the same conclusion as I was going to sleep last night, but not for the correct reasons you state in your comment.
How about this: use the same out of process call, only instead of a callback function, send cCB information for it to send a WM_COMMAND message to VB6S, spoofing a state change of one of its controls, say a button, butCB? Then ExecuteCallback(..) becomes ExecuteClickback(..)
void __stdcall ExecuteClickback(WORD butID, HANDLE hBut, HANDLE hVB6S, double microS){};
The timerWork object does a PostMessage of a WM_COMMAND to hVB6S's Form with:
wParam = (DWORD) ( (butID << sizeof(WORD)) + (WORD) BN_CLICKED ); lParam = hBut;
Then, VB6S's form should raise its butCB_Click() event. That event handler would have the instruction to call My74Processor(). Since VB6S is necessarily in a pure message wait state once the call to ExecuteClickback is made, the arrival of the WM_COMMAND should "look" to VB6S just like the user actually clicked the button.
Related
I'm doing winapi programming and i usually have a problems related to WM_TIMER msg: for example, when i put function that activates when WM_TIMER msg is called, like Update() function for example, this function is still called even though i killed timer. What's the main problem right now is that when i believe that i deleted the class that contain Update() function, this class still calls Update() function even though i killed timer and this class first, and because of this, i get memory error because this Update() function deals with attributes that are already deleted in previous delete function. Is there any solution to make WM_TIMER be called after certain task is done?
The WM_TIMER message is actually a flag -- when some timer expires, the flag is set to generate a single WM_TIMER event if the message queue is empty and GetMessage is called.
This avoids clogging up the system with many WM_TIMER messages and collapses multiple expired timers into one, but has the disadvantage of delivering the WM_TIMER message after all other messages (WM_PAINT is treated similarly).
So what you are seeing is that the timer you have killed has already elapsed and the flag is set, but the message will not be delivered until your program is otherwise idle.
You want to keep a flag to memorize whether you are actually waiting for a timer event.
In an application with multiple timers in parallel you'd keep a list of active timers, and use the Windows timer mechanism to schedule the next timer to elapse, and in the handler, invoke all sub-handlers whose deadlines are past.
It's known that, in cases when one needs comunicate between UI thread and working thread, an hidden window must be created because of thread safety(handle reconstruction).
For exemplify:
Form1 has N dynamicaly created TProgressBar instances with the same name of a background running .
Is always garanteed that WM_REFRESH will only be called inside Task Thread.
Form1 has H : THandle property that allocates the following procedure:
procedure RefreshStat(var Message: TMessage); message WM_REFRESH;
Inside RefreshStat, in cases when there is only 1 background thread I could easily use L and W parameter to map Task Id and position.
I don't know if the title says what I want to know, but let's imagine if we have an application that has multiple background tasks running.
In my case I use TProgressBar to report progress the done.
Does AllocateHwnd garantee that all messages arrives with no race condition the hidden window?
What happens if two or more tasks post the message at the same time?
If this needs to be controled manually, I wonder if there is something else to do besides creating another message loop system in the custom message.
I hope the question is clear enough.
The message queue associated with a thread is a threadsafe queue. Both synchronous and asynchronous messages from multiple other thread are delivered safely no harmful date races. There is no need for any external synchronization when calling the Windows message API functions like SendMessage and PostMessage.
If two threads post or send messages to the same window at the same time, then there is no guarantee as to which message will be processed first. This is what is known as a benign race condition. If you want one message to be processed before the other then you must impose an ordering.
I have an application, where most of the actions take some time and I want to keep the GUI responsive at all times. The basic pattern of any action triggered by the user is as follows:
prepare the action (in the main thread)
execute the action (in a background thread while keeping the gui responsive)
display the results (in the main thread)
I tried several things to accomplish this but all of them are causing problems in the long run (seemingly random access violations in certain situations).
Prepare the action, then invoke a background thread and at the end of the background thread, use Synchronize to call an OnFinish event in the main thread.
Prepare the action, then invoke a background thread and at the end of the background thread, use PostMessage to inform the GUI thread that the results are ready.
Prepare the action, then invoke a background thread, then busy-wait (while calling Application.ProcessMessages) until the background thread is finished, then proceed with displaying the results.
I cannot come up with another alternative and none of this worked perfectly for me. What is the preferred way to do this?
1) Is the 'Orignal Delphi' way, forces the background thread to wait until the synchronized method has been executed and exposes the system to more deadlock-potential than I am happy with. TThread.Synchronize has been re-written at least twice. I used it once, on D3, and had problems. I looked at how it worked. I never used it again.
2) I the design I use most often. I use app-lifetime threads, (or thread pools), create inter-thread comms objects and queue them to background threads using a producer-consumer queue based on a TObjectQueue descendant. The background thread/s operate on the data/methods of the object, store results in the object and, when complete, PostMessage() the object, (cast to lParam) back to the main thread for GUI display of results in a message-handler, (cast the lParam back again). The background threads in the main GUI thread then never have to operate on the same object and never have to directly access any fields of each other.
I use a hidden window of the GUI thread, (created with RegisterWindowClass and CreateWindow), for the background threads to PostMessage to, comms object in LParam and 'target' TwinControl, (usually a TForm class), as WParam. The trivial wndproc for the hidden window just uses TwinControl.Perform() to pass on the LParam to a message-handler of the form. This is safer than PostMessaging the object directly to a TForm.handle - the handle can, unfortunately, change if the window is recreated. The hidden window never calls RecreateWindow() and so its handle never changes.
Producer-consumer queues 'out from GUI', inter-thread comms classes/objects and PostMessage() 'in to GUI' WILL work well - I've been doing it for decades.
Re-using the comms objects is fairly easy too - just create a load in a loop at startup, (preferably in an initialization section so that the comms objects outlive all forms), and push them onto a P-C queue - that's your pool. It's easier if the comms class has a private field for the pool instance - the 'releaseBackToPool' method then needs no parameters and, if there is more than one pool, ensures that the objects are always released back to their own pool.
3) Can't really improve on David Hefferman's comment. Just don't do it.
You can implement the pattern questioned by using OTL as demonstrated by the OTL author here
You could communicate data between threads as messages.
Thread1:
allocate memory for a data structure
fill it in
send a message to Thread2 with the pointer to this structure (you could either use Windows messages or implement a queue, insuring its enque and dequeue methods don't have race conditions)
possibly receive a response message from Thread2...
Thread2:
receive the message with the pointer to the data structure from Thread1
consume the data
deallocate the data structure's memory
possibly send a message back to Thread1 in a similar fashion (perhaps reusing the data structure, but then you don't deallocate it)
You may end up with more than 1 non-GUI thread if you want your GUI not only live, but also responding to some input, while the input that takes long time to be processed is being processed.
I'm working on a project to inject a shared library in a program with LD_PRELOAD.
My injected library creates a new thread when it is injected into the program. All logic happens in this thread (like analyzing network traffic and so on).
First you need to know this about the program that is being preloaded. It is a client application that encrypts every packet, written to a static buffer, that it sends to the server. I found the function that encrypts and sends the packets in the client and I was able to detour it. So now I can just modify the static buffer and let the 'send' function encrypt the buffer and send the buffer to the server.
But now I have a problem: what if I change contents of the static buffer in my library's thread (so that I can send a fake packet) and at the same time the program's thread changes the static buffer too? That would cause a crash.
I need some kind of synchronization.
So I've been thinking of some solutions:
Find every function in the program that changes the buffer, detour them and add a mutex to that call or something like that. Would take like ages though...
Find a way to execute my piece of code, that changes the buffer, in one block. So my piece of code actually gets executed at once, without POSIX threads switching to other threads. Is this even possible?
Make my application synchronous and cry.
Can anyone come up with a better solution? Or do you know how to make solution 2 possible?
Thanks in advance,
Gillis
If you detoured the 'send' function and you have the code of your 'detoured send' in your preloaded library it means that when the main thread calls 'send', your 'detoured send' code will be executed in the main thread's context, your thread is doing nothing at that moment. If you have more than one 'main thread' that could potentially call 'send', then you need synchronization in your 'detoured send'.
Alternatively, it you really want to process something in your new 'injected' thread you can:
1) in your 'detoured send' (invoked from main thread's context): pass the data to your thread
and wait untill it finishes processing the data (notice: the main thread is waiting).
Does asynchronous call always create a new thread?
Example:
If JavaScript is single threaded then how can it do an async postback? Is it actually blocking until it gets a callback? If so, is this really an async call?
This is an interesting question.
Asynchronous programming is a paradigm of programming that is principally single threaded, i.e. "following one thread of continuous execution".
You refer to javascript, so lets discuss that language, in the environment of a web browser. A web browser runs a single thread of javascript execution in each window, it handles events (such as onclick="someFunction()") and network connections (such as xmlhttprequest calls).
<script>
function performRequest() {
xmlhttp.open("GET", "someurl", true);
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4) {
alert(xmlhttp.responseText);
}
}
xmlhttp.send(sometext);
}
</script>
<span onclick="performRequest()">perform request</span>
(This is a nonworking example, for demonstration of concepts only).
In order to do everything in an asynchronous manner, the controlling thread has what is known as a 'main loop'. A main loop looks kind of like this:
while (true) {
event = nextEvent(all_event_sources);
handler = findEventHandler(event);
handler(event);
}
It is important to note that this is not a 'busy loop'. This is kind of like a sleeping thread, waiting for activity to occur. Activity could be input from the user (Mouse Movement, a Button Click, Typing), or it could be network activity (The response from the server).
So in the example above,
When the user clicks on the span, a ButtonClicked event would be generated, findEventHandler() would find the onclick event on the span tag, and then that handler would be called with the event.
When the xmlhttp request is created, it is added to the all_event_sources list of event sources.
After the performRequest() function returns, the mainloop is waiting at the nextEvent() step waiting for a response. At this point there is nothing 'blocking' further events from being handled.
The data comes back from the remote server, nextEvent() returns the network event, the event handler is found to be the onreadystatechange() method, that method is called, and an alert() dialog fires up.
It is worth noting that alert() is a blocking dialog. While that dialog is up, no further events can be processed. It's an eccentricity of the javascript model of web pages that we have a readily available method that will block further execution within the context of that page.
The Javascript model is single-threaded. An asynchronous call is not a new thread, but rather interrupts an existing thread. It's analogous to interrupts in a kernel.
Yes it makes sense to have asynchronous calls with a single thread. Here's how to think about it: When you call a function within a single thread, the state for the current method is pushed onto a stack (i.e. local variables). The subroutine is invoked and eventually returns, at which time the original state is popped off the stack.
With an asynchronous callback, the same thing happens! The difference is that the subroutine is invoked by the system, not by the current code invoking a subroutine.
A couple notes about JavaScript in particular:
XMLHttpRequests are non-blocking by default. The send() method returns immediately after the request has been relayed to the underlying network stack. A response from the server will schedule an invocation of your callback on the event loop as discussed by the other excellent answers.
This does not require a new thread. The underlying socket API is selectable, similar to java.nio.channels in Java.
It's possible to construct synchronous XMLHttpRequest objects by passing false as the third parameter to open(). This will cause the send() method to block until a response has been received from the server, thus placing the event loop at the mercy of network latency and potentially hanging the browser until network timeout. This is a Bad Thing™.
Firefox 3.5 will introduce honest-to-god multithreaded JavaScript with the Worker class. The background code runs in a completely separate environment and communicates with the browser window by scheduling callbacks on the event loop.
In many GUI applications, an async call (like Java's invokeLater) merely adds the Runnable object to its GUI thread queue. The GUI thread is already created, and it doesn't create a new thread. But threads aren't even strictly required for an asynchronous system. Take, for example, libevent, which uses select/poll/kqueue, etc. to make non-blocking calls to sockets, which then fires callbacks to your code, completely without threads.
No, but more than one thread will be involved.
An asynchronous call might launch another thread to do the work, or it might post a message into a queue on another, already running thread. The caller continues and the callee calls back once it processes the message.
If you wanted to do a synchronous call in this context, you'd need to post a message and actively wait for the callback to happen.
So in summary: More than one thread will be involved, but it doesn't necessarily create a new thread.
I don't know about javascript, but for instance in the Windows Forms world, asynchronous invocations can be made without multiple threads. This has to do with the way the Windows Message Pump operates. Basically a Windows Forms application sets up a message queue through which Windows places messages notifying it about events. For instance, if you move the mouse, messages will be placed on that queue. The Windows Forms application will be in an endless loop consuming all the messages that are thrown at it. According to what each message contains it will move windows around, repaint them or even invoke user-defined methods, amongst other things. Calls to methods are identified by delegates. When the application finds a delegate instance in the queue, it happily invokes the method referred by the delegate.
So, if you are in a method doing something and want to spawn some asynchronous work without creating a new thread, all you have to do is place a delegate instance into the queue, using the Control.BeginInvoke method. Now, this isn't actually multithreaded, but if you throw very small pieces of work to the queue, it will look like multithreaded. If, on the other hand you give it a time consuming method to execute, the application will freeze until the method is done, which will look like a jammed application, even though it is doing something.