Re: A mailslot question

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

BTW: the same problem exists whether you use a single buffer or multiple
buffers - if you have a bug in your code it will leak memory or else
deadlock. The correct solution to this problem is not to avoid a design
because it _can_ leak memory, but to code it so that it _doesn't_ leak
memory. Just like the code that MS wrote in SendMessage _can_ deadlock
because it uses thread sync, but they wrote it so it _doesn't_ unless you do
something brain-dead while processing the message (like make another call to
SendMessage)



The purpose of a separate heap is not to contain a leak, but to ensure that
the producer can't overrun the consumer (ie under heavy system load) by
failing allocations if it gets too far ahead.



The advantage of a single buffer is that it might have a more constant and
predictable memory usage; but it will limit performance, by preventing
virtually all parallelism, defeating the advantage of a separate thread by
introducing an unneeded sync point, and increase total overhead for the
processing of a mail slot messages by consuming additional system resources
(KM buffers on the mail slot & sync objects).


"R.Wieser" <address@xxxxxxxxxxxxx> wrote in message
news:e7JCiB%23QJHA.1164@xxxxxxxxxxxxxxxxxxxxxxx
Hello m,

The thread that reads from the mailslot allocates a buffer, fills it
with a message, and then hands it off to the thread that will
process it via PostMessage.

Yes, I did think of that method too. But just a simple mistake (for
instance, not handling the PostMessage) and that memoryblock will keep on
existing (quietly depleting resources).

Your idea for a seperate heap sounds nice, but only limits the
resource-depletion to the mailslot. But if-and-when that heap fills-up
because of the above the program is as dead in the water as otherwise ...

The nice thing of using a local buffer and SendMessage is that no such
situation can happen.

But thanks for the suggestion though.

code and possible to the users who use it. The most efficient solution
to your problem is likely to continue to pass the window handle to the
thread proc

That is what I'm doing now. Together with the MailSlot handle and the
WM_??? message to send to the parent.

but you could use window class and instance information to find
the right window dynamically. Of course, if you go this route, be
careful that you post to the right instance when multiple instances
of your app are running.

I hoped I would be able to limit my search to the current instance
(GetModuleHandle). But to be honest, I did not search for it yet.

Regards,
Rudy Wieser


-- Origional message
m <m@xxx> schreef in berichtnieuws
eGjaAz4QJHA.1164@xxxxxxxxxxxxxxxxxxxxxxx
What's wrong with the even easier method of using producer-consumer
model?
The thread that reads from the mailslot allocates a buffer, fills it with
a
message, and then hands it off to the thread that will process it via
PostMessage. The thread that sits in a message loop will just need to
free
the buffer after it has processed the message. No memcpy or complex sync
required. If you want to be careful about memory allocation, you can
create
a low-fragmentation heap just for these buffers to limit the potential
for
address space fragmentation and control the maximum number of messages
that
can be posted ahead of the reader.



As Volodymyr mentions, in Win32, a process can have a large number of
threads (limited by system resources) and each one can have zero or more
top-level windows, each with zero or more child windows (again limited by
system resources). Each of these is treated equally by the OS, so the
distinction of a 'main' window exists only to the programmers who wrote
the
code and possible to the users who use it. The most efficient solution
to
your problem is likely to continue to pass the window handle to the
thread
proc but you could use window class and instance information to find the
right window dynamically. Of course, if you go this route, be careful
that
you post to the right instance when multiple instances of your app are
running.





.

Relevant Pages

  • Re: Discovering variable types...
    ... >- but I suppose MS expect us to use wrappers ... memory allocations for your variables from disk as well. ... >They most certainly are of fixed size, changing the size of a String ... >>me to keep buffer size and current postion right in the memory block. ...
    (comp.lang.pascal.delphi.misc)
  • How do I debug PCI resource allocation problems
    ... problems on a new mainboard with Intel Q35 chipset and a shared memory ... <7>PCI: ... MEM window: disabled. ... VESA VGA frame buffer device ...
    (Linux-Kernel)
  • Re: Discovering variable types...
    ... >memory it points to is on the heap. ... sequentially reading data, if one is randomly reading records, then a ... >project is what's prompting me to improve disk access. ... from a memory buffer I can do it in about a second. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Multicast Directshow Graph Bridging, COW Rustling, & the Use of Portable Holes in Cartoon Ph
    ... memory to share buffer pools across processes and works pretty well. ... You get two basic Direct Show filters, ... issue each GMF-source a virtual memory alias with COW ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: PCI bus-master and large contiguous memory buffers
    ... I built my scatter gather list in SRAM that was on my device, ... could have done it in system memory had I needed to. ... interrupt when a buffer was filled, the application would save the buffer to ... beginning of the recording I made a device IO control call to my driver. ...
    (microsoft.public.development.device.drivers)