The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Will this be equal to an asynchronous call?

I need to have a functionality similar to a function pointer.

I have two Windows services, say, WinServ1 and WinServ1. WinServ1 has a method DoAsyncCall() and a method DoAfterReturn(). Ideally, it should be able to send the pointer of DoAfterReturn to a method in WinServ2. Once it is over, it should invoke the DoAfterReturn method.

WinServ2 does not support asynchronous calling. It can't accept a function pointer and invoke it after its work is over.

If the object in WinServ1 follows the Singleton pattern, will calling the method DoAfterReturn() directly from a method in WinServ2 be equal to an asynchronous call? If it is a Singleton, creating an instance should return me the one that's been already created.
Senthilnathan N.S. Send private email
Wednesday, March 28, 2007
 
 
No.

Then again, you and I probably have different definitions of asynchronous.
TheDavid
Wednesday, March 28, 2007
 
 
Doesn't an asynchronous call help us to invoke something in the same instance of an object at a later point? If it's okay to create a new instance and call a method, we wouldn't have the need to send a function pointer.

You define asynchronous in a similar sense? Or is it different?
Senthilnathan N.S. Send private email
Wednesday, March 28, 2007
 
 
Yes. If I understand your terminology. But with regard to implementation, you cannot call a function pointer in another service, you need a non-blocking type mechanism like PostMessage or SendMessageTimeout. But anyway, when WinServ1 calls WinServ2::DoAsyncCall() with this mechanism, then it will not be waiting for WinServ2 and therefore it is an asynchronous call. WinServ2 calls WinServ1::DoAfterReturn() by way of the same sort of mechanism to notify WinServ1 of the completion.
Ben Bryant
Wednesday, March 28, 2007
 
 
Ben Bryant is closer to what I'm thinking of; an asynchronous call is one that doesn't have to worry about being blocked, delayed, lost, or other such interruptions.

I will also point out that architectually speaking, asynchoronous calls - the way you're using them - are perhaps not the best solution. For example, what happens if WinServ1 asks WinServ2 to do something and then crashes while waiting for a response from WinServ2?

The presence of DoAfterReturn() implies that WinServ1 needs a response from WinServ2 and by implication, is not asynchronous. Multi-threaded perhaps in the sense that it can do something else while waiting.

But I apologize - it may just be the terminology that's tripping me up. Simply renaming the DoAfterReturn() function to something like DoThisWheneverServ2SendsMessage() would be a little clearer - the function gets called whenever Serv2 sends a message, regardless of when it actually arrives, and that, I'd consider to be asynchronous.
TheDavid
Wednesday, March 28, 2007
 
 
I would re-write what I said ealier... it all depends on the mechanism, but no matter what, you won't be passing a function pointer because it needs to be a pre-arranged "callback" point, assuming both services are singletons. SendMessageTimeout (I'm the one that mentioned it) is not applicable because you are talking about kicking off a process, not waiting only if it completes in a certain amount of time, unless WinServ2 was creating a worker thread and then returning. PostMessage or asynchronous COM calls might be appropriate.

>what happens if WinServ1 asks WinServ2 to do something and then crashes while waiting for a response from WinServ2?

This is why you DO need asynchronous calls, because WinServ1 will not be "waiting," it only knows to do something if WinServ2 notifies of completion. I mean, it might want to track time and do something if too much time has passed, but that is a different issue. If WinServ2 is performing its process independently, then WinServ1 needs to be designed in such a way that it handles a situation where WinServ2 never gets back to it before it is shut down or something else happens to it.
Ben Bryant
Wednesday, March 28, 2007
 
 
Thanks TheDavid and Ben.

"...Simply renaming the DoAfterReturn() function to something like DoThisWheneverServ2SendsMessage() would be a little clearer - the function gets called whenever Serv2 sends a message, regardless of when it actually arrives, and that, I'd consider to be asynchronous. "

What you have said above is exactly what I was looking for. I just wanted to convey the scenario. You can change the terminology as much as you want. If it makes for easy understanding, I'm all the more for it.

"If WinServ2 is performing its process independently, then WinServ1 needs to be designed in such a way that it handles a situation where WinServ2 never gets back to it before it is shut down or something else happens to it."

Wouldn't we need a queue for this?
Senthilnathan N.S. Send private email
Thursday, March 29, 2007
 
 
WinServ2 could use a queue if it was fielding multiple requests sequentially. If it is just on/off, processing or not, then no.
Ben Bryant
Thursday, March 29, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz