Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

single-instance filter

101 views
Skip to first unread message

haipt

unread,
Dec 9, 2004, 9:46:54 PM12/9/04
to
Hi all,

I'm trying to do a single-instance filter, which would be able to access
some common global data across different applications which instantiate it.
Could anyone advise me on the architecture to achieve that?
For example, now I want my "Bouncing Ball" to run exactly the same (i.e the
ball at the same position) when I run it in Graph Edit and in my application
simultaneously.

I've tried modifying the CreateInstance() inside the BouncingBall, so that
it becomes a singleton design, but that only works when I open two
BouncingBall in GraphEdit (i.e. from the same app). The moment I open it in
my app it would create and return another instance of Bouncing Ball.

Thanks a lot for your suggestion.
Hai.


Alessandro Angeli [MVP::DigitalMedia]

unread,
Dec 9, 2004, 10:56:56 PM12/9/04
to
haipt wrote:

This is not really a DirectShow question. Anyway...

You need to use a shared memory buffer and a pair of named
global mutex and event for synchronization. It's up to how
to generate the data and synchronized the processes.

You can create the mutex and event objects using
CreateMutex() and CreateEvent() and giving them a name
(better use unique names, e.g. string that contain some
GUID, like your own CLSID).

You can create a shared memory buffer using the
memory-mapped file APIs (CreateFileMapping(); again, better
choose a unique name) or enclosing the external buffer
declaration in a data_seg() #pragma directive (which
actually instructs the compiler to create a memory-mapped
file for you):

#pragma data_seg("shared")
BYTE buffer[1024];
#pragma data_seg()

and then telling the linker to make this segment shared
(/SECTION:shared,RWS).

Maybe the MFC class CSharedFile is another way to create a
memory-mapped file.

--

// Alessandro Angeli
// MVP :: Digital Media
// a dot angeli at psynet dot net


haipt

unread,
Dec 9, 2004, 11:13:00 PM12/9/04
to
"Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.in.the.net> wrote in
message news:OPbtMxm3...@TK2MSFTNGP11.phx.gbl...

Oh, this's very informative. I'll look into it immediately. Thanks a lot for
your answer Allesandro.


The March Hare [MVP]

unread,
Dec 10, 2004, 12:34:10 AM12/10/04
to
On Fri, 10 Dec 2004 12:13:00 +0800, haipt wrote:

<snip>
> your answer Allesandro.

Alessandro: still better than Alessandra <g>

Alessandro Angeli [MVP::DigitalMedia]

unread,
Dec 10, 2004, 7:50:30 AM12/10/04
to

I always told my mother "Alessandro" was too long a name and
she should have chosen a shorter and simpler one :-))

haipt

unread,
Dec 12, 2004, 8:44:16 PM12/12/04
to

"Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.in.the.net> wrote in
message news:uKbGGdr3...@TK2MSFTNGP15.phx.gbl...

I'm sorry to misspell your name, Alessandro (a careful programmer should
never misspell anything actually :) ). Anyway, your suggested method works
really well in my case. Initially i declared like this:
#pragma data_seg("SHARED")
char buf[1000];
#pragma data_seg()
#pragma comment(linker, "/section:SHARED,RWS")
(i'm using VC.NET 2003)

Then the two processes did see the same buf's global address, but somehow
whenever one updated it, the other could not see the update.
After a good few hour tracing the problem, i realized that it's due to my
buf's not initialized. So I changed it to char buf[1000]="", and from there
on it works perfectly for me. I've got no explanation except the guess that
it's due to some linker's internal decision.

So thanks again, Alessandro.
Hai.


Alessandro Angeli [MVP::DigitalMedia]

unread,
Dec 12, 2004, 11:51:43 PM12/12/04
to
haipt wrote:

> After a good few hour tracing the problem, i realized
> that it's due to my buf's not initialized. So I changed
> it to char buf[1000]="", and from there on it works
> perfectly for me. I've got no explanation except the
> guess that it's due to some linker's internal decision.

I don't think that's the case: when you declare an array
pointer but you do not initialize it, you're only reserving
space for the pointer while, when you initialize it, you are
reserving space for the array but not the pointer. In the
first case, your processes were sharing the pointer's memory
location but not the actual buffers which were allocated
outside shared memory unless you did some memory-mapped file
"magic" of you own. This scenario was also dangerous because
one process would end up using the other's pointer value
which was not necessarily a valid pointer in its own memory
space.

> So thanks again, Alessandro.

You're welcome :-)

0 new messages