Prev: Advice on good Application Programming Practices
Next: how to get 2 button press
From: ScottMcP [MVP] on 12 Jan 2010 22:40
On Jan 12, 1:38 pm, "Stanza" <sta...(a)devnull.com> wrote:
> Thanks for the suggestions. If I wanted the caller to be able to read the
> gathered data as it was being generated, how could I do that? I'm thinking
> of something like (in UNIX) an unnamed pipe, where a thread in the DLL would
> write data to the pipe and the caller in another thread would read it from
> the pipe, so that there would be interleaved writing and reading, without
> the caller having to wait for the whole file to be read (or having the
> caller thread tied up doing the actual data gathering from the file inside
> the DLL).

There are numerous ways to do interthread data communication. If the
main thread implements a GUI then PostMessage is the usual choice,
since a GUI thread is built around accepting messages. The DLL thread
puts some data in a heap buffer and passes the address in PostMessage.
The GUI thread processes the data and frees the buffer.
From: Michael Wojcik on 12 Jan 2010 12:38
ScottMcP [MVP] wrote:
>
> If you do not meet this requirement then another solution is to export
> a function from the DLL that will free the memory it allocated.

This is almost always the better approach anyway. For example, it
gives you a single place to instrument if you want to track where
memory allocated by your DLL is freed. (Obviously, this works even
better if your DLL calls the function too.)

It also gives you the opportunity to change how the DLL manages memory
in future releases.

In general, libraries should abstract implementation details away from
the caller, including memory management.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
First  |  Prev  | 
Pages: 1 2
Prev: Advice on good Application Programming Practices
Next: how to get 2 button press