Async callback of a function (through pointer) from a DLL

fatherdougalmag

My app loads a DLL and I was hoping that I could pass the DLL a function pointer so that, at some point, the DLL can call back into my app. But it seems that when the DLL is running within it's own context a wobbly is thrown when it tries to call the call back.

I know there are work-arounds (using shared events) but I thought I'd throw this out there.

Evil Phil

What language?

fatherdougalmag

It's more the method I'm interested in (what Win32 API to call) but C is what I'm working in.

scojones

Google for win32 API interoperability

Merrion

Win32 DLLs are loaded in the context of the calling application, so I see no reason why the function pointer you pass in shouldn't work?

However another way might be to pass in a WaitHandle and then set that wait handle in the DLL when you want to signal the app that something has happened. You'd need a thread in the app to watch that wait handle.

bonkey

Going with what Merrion just said...I'd ask "what type of DLL are you talking about"

F'r example...COM objects can be bundled in DLLs, but you interact with a COM-based DLL entirely differently to a C-API-based DLL.

Similarly, if you're talking about cross-process communication (which it would appear you are doing), the immediate question is what type of this are you using.

jc

fatherdougalmag

We're talking about a regular DLL here.

A DLL exported function can directly call the call back as part of a call to that exported function. After all, the EXE's context is initiating the call there so there is no problem.

It's when a thread running in the context of the DLL tries to call the function, I'm guessing that it's a no no because the function pointer isn't valid in the context of that (the DLL's) process. It's like the function pointer from the exe needs to be mapped into the DLL's process space so it can access/execute it legally.

The more I think about it, the more impossible it sounds so I'm working on a shared event implementation. Thanks anyway.

bonkey

fatherdougalmag wrote:

We're talking about a regular DLL here.

Are we?

...because the function pointer isn't valid in the context of that (the DLL's) process.

But DLL's don't run in their own process. They run in the process of the application which invoked them. This is what prompted my "are we" above...

If you have seperate processes, then you have to be using one of the cross-process communication technologies and its not just a bog-standard Windows DLL that we're dealing with here. If you're dealing with a normal Windows DLL, then you're not going across seperate processes, then there is one and only one address-space, so the address of something must remain valid, which is effectively what a pointer to a function is.

There is something at the back of my head telling me that there is a limit on what resources are available to sub-threads in a given process. So if your DLL is spawning child threads, these may not be able to access resources in the main thread, which is what the application will be running in. This could/would mean that a child-thread could not invoke a call-back to a function in the parent-thread. Is this what you mean?

The more I think about it, the more impossible it sounds

What you're describing sounds like standard call-back functionality, which is most certainly possible....unless its a multi-threading (as opposed to cross-process) issue you're running into.

jc

fatherdougalmag

I've got things going based around shared events but if you want to pursue it further, I have two applications, A1 and A2, and a DLL, D.

A1 loads D. A2 then loads D. There is a shared data segment in the DLL. The DLL creates a thread when A1 loads it. The idea was that when A2 loads D, it passes a function pointert to D. I was hoping that the thread running in D would be able to call the function pointer passed by A2 but I get an exception.

bonkey

fatherdougalmag wrote:

I was hoping that the thread running in D would be able to call the function pointer passed by A2 but I get an exception.

Ah.

As a matter of interest....which process is attempting to callback to the function pointer?

As I understand things, there is effectively a seperate copy of the DLL loaded into each address space. The "shared data segment" is obviously common, but thats not whats significant here.

When you pass a function pointer into the DLL, you're telling the DLL what address in the current memory-space this function is to be found in. If it is called from the same memory-space, it should work. If not, then it won't.

In other words, A2 should be able to have its address called back by the copy of D loaded into the A2 memory space.. The copy of D loaded into the A1 memory space is a completely seperate instance (although both instances of D have a common data-store as you mentioned), in a completely seperate memory-space, so it can't do the callback.

Thats the thing to remember - there are two copies of D loaded but which are capable of sharing information...not one copy being shared between both applications.

Shared events is the right way to go in this case.

jc

fatherdougalmag

That's what I had suspected from the outset and I was hopping that there was some way of mapping the function pointer into the DLL thread's context. But I guess that's a part of what LoadLibrary does in the first place. I was just wondering if it was possible. I'm spending too much time in kernel mode where this kind of thing is possible.

Thanks for the follow through anyway.

theexis

You'd have to use one of the many forms of interprocess communication to have this work, or, since you have the function pointer as an address that is meaningful to the process you want to run the function within, take a look at CreateRemoteThread.