Alex,

Did you check out IMessageFilter?

Unless I've misunderstood your problem, it appears that you
could register a messagefilter on your server's STA which
uses IMessageFilter::HandleInComingCall to have the client retry
when the calltype is CALLTYPE_TOPLEVEL_CALLPENDING, i.e. return
SERVERCALL_RETRYLATER for
this case. Written this way, the messagefilter should still allow reentry
on the same thread in case you need to support callbacks.

I assume you just want incoming calls to be handled serially...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesdkr/htm
/_wcesdk_com_imessagefilter__handleincomingcall.asp

-----Original Message-----
From: Alex Smith [mailto:asmithMATRA.CO.UK]
Sent: Monday, September 24, 2001 2:09 AM
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Out of process singleton

Hmmm,

Thanks for all of your help on this one. Unfortunately, all solutions
involving locking/member variables etc were tried but led to deadlocks,
presumably because the second call into the object locked it so any return
from a COM function call made during the first call was unable to be
processed. Sorry about the long sentence!

Anyway, I got round the problem using Service Dependencies and delaying the
start of the second client until the first call had completed. This means
they take a few more seconds to start up but do so cleanly. This is
probably the correct solution given the design of the components at the end
of the day. I'm surprised that I haven't come across this sort of problem
before though - it seems like a royal pain to me.

Thanks again.

_________
Alex Smith

Project Manager
MATRA Systems (UK) Ltd <http://www.matra.co.uk>
Registered in Cardiff 2642797
Tel:+44 (0)2380 684 700 / Fax:+44 (0)2380 619 828
The content of this email is subject to MATRA's standard company disclaimers
which can be found at: http://www.matra.co.uk/EmailDisclaimer.html

-----Original Message-----
From: Philip Bowden [mailto:pwbowdenMATRA.CO.UK]
Sent: 20 September 2001 18:43
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Out of process singleton

Steve's right you big silly. Perhaps you should take some of his advise! I
suggest you have a initialised flag and an initialising flag, and pump the
message loop if you are already initialising, but not initialised.

Cheers

Phill

Phill Bowden - Software Engineer
MATRA Systems (UK) Ltd <http://www.matra.co.uk>
Registered in Cardiff 2642797
Tel:+44 (0)2380 684 700 / Fax:+44 (0)2380 619 828
The content of this email is subject to MATRA's standard company
disclaimers which can be found at:
http://www.matra.co.uk/EmailDisclaimer.html

-----Original Message-----
From: Steve Johnson [mailto:sjohnson3TSYSTEMS.COM]
Sent: 20 September 2001 18:23
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Out of process singleton

Yes, I am sure that a STA can be reentered. When a COM call leaves the
apartment, the thread of execution (causality) leaves the STA thread. This
leaves the STA available to process incoming calls.

Kernel synchronization objects are useless to solve this problem. The
reason is that they work on the principle of thread affinity. This ensures
that only one thread owns the object at any given time. This is useless in
your situation because the STA executes all incoming calls on its one
thread.

Illustration:

1 - One client calls Method1
2 - In Method1, the object enters CriticalSection1, which now belongs to the
STA thread.
3 - Method1 makes a COM call outside the apartment, leaving the STA free to
process incoming calls.
4 - Second client calls Method1
5 - Method1 enters CriticalSection1 happily, because the STA thread already
owns CriticalSection1 from the previous call.

As you can see, this provides no protection.

One suggestion to solve this would be to have a member boolean, say,
m_bLock. Then you simply check the value of m_bLock to determine whether
execution is allowed. If you need further protection, you can use the
InterlockedX family of APIs to set and reset the boolean.

Illustration:

1 - Method1 is called
2 - Check that m_bLock is FALSE
3 - Set m_bLock to TRUE
4 - Make outgoing COM calls
5 - Method1 is called by another client
6 - m_bLock is TRUE, so reject the call.

Others on the list may have much better ideas as I've never had to solve
this problem myself.

Steve Johnson
3t Systems

mailto://sjohnson3tsystems.com
(303) 858-8800 x265

> Are you sure about that Steve? Surely the whole point of a
> Single Threaded
> Apartment is that the (in this case single) object instance can only be
> entered once and has to complete before the next function call to
> it can be
> serviced?
>
>
> If you are sure, How can I mutex this object's method so that it acts in a
> single threaded fashion when I need it to without causing deadlocks. All
> the methods I did try for this (Critical Section, Mutex, Windows Message
> with AtlWaitWithMessageLoop) caused deadlocking.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]