Re: PostMessage and unprocessed messages

"David Lowndes" <DavidL@example.invalid> ha scritto nel messaggio
news:kfers3574ebhgth9e2smhgtih4sr0dvnq1@4ax.com...


These are cases when I do miss a garbage collector.
Multithreading is already complex of its own, and can introduce subtle bugs,
so adding memory management complexity (and potential memory leaks) to the
already present complexity is kind of too much for me :)

I don't know details about OP's problem, however, to add to what others
wrote, I would like to suggest to implement a custom memory allocator for
message data.
If message size and message frequency allow that, I would keep a linked list
of created messages from the sender, i.e. the sender creates a message and
sends a pointer to this message to the receiver, but also the sender stores
a linked list of pointers to sent messages (the sender is the "owner" of the
heap memory allocated for message data: the sender allocates memory, and the
sender will delete it).

The receiver does not delete the messages (the message owner is the sender),
it just reads them.

So, when the sender goes into termination state, it scans the linked list
and deletes all created message data.

So, in this case, even if some sent messages are unprocessed by the
receiver, there is no memory leak, because all sent message data is deleted
by the sender.

In general, to attack more complex problems, I think that we need more
powerful tools.
For example, to build the old DOS apps, I think that people used assembly.
But if we move to a more complex level, like building *GUI* apps, I think
that OK, assembly might also be used to call Win32 functions... but it is
very very complex to write a GUI app in assembly, and more powerful tools
like object-oriented languages like C++ and frameworks like MFC help a lot
here.

So, the next level of complexity is multithreading. I have no big experience
with multithreading (I think that Joe and others can more to say about
that), but my feeling is that C++ is kind of "assembly language" for
multithreading, it is too low-level to build multithreading apps in a
productive way.

For example, .NET offers the BackgroundWorker component: it helps a lot in
developing apps when we have background threads that do long computations,
and don't lock the main GUI thread.
And moreover we don't have problems when we allocate memory on the managed
heap, because the garbage collector will free that memory, so we can
concetrate more on the specific multithreading problem, and don't waste our
"brain cycles" on details like memory deallocation, etc.

I would very much like having some C++ standard components to manage
multithreading in a productive way, like a robust background worker thread
class, or some decent garbage collector for memory passed between threads.

I think that adding some multithreading features to C++ would be very
appreciated, so we can move from the "assembly language" level for
multi-threading development, to a more productive level (like when
programmers moved from assembly language to higher-level languages, like C
and C++).

Giovanni