callAndWait( ) implementation issues?

[Alasdair Allan]

I'm currently getting a bit worried by the implementation issues  
surrounding the callAndWait( ) method in the Hub. The current scheme  
is that a client can call this and expect a synchronous response from  
the Hub. However there seems to be no way to synchronously call a  
client.

Clients only have a recieveCall( ) method, and then asynchronously  
return a reply( ) call to the Hub in response. In theory the Hub  
takes this hopefully speedily returned reply( ) and uses it as a  
return value for the callAndWait( ) which has been hanging with an  
open socket all the time.

However this reply( ) call will almost certainly be handled by a  
separate thread (or forked process) or at least a different part of  
the Hub software than the (hanging open) callAndWait( ) method. I'm  
having real difficulty imagining how the information in the  
asynchronous reply( ) call is supposed to make its way over to the  
synchronous callAndWait( ) except by a complicated system of thread  
semaphores and shared variables.

I can certainly go off an implement this model, however this is going  
to severely limit the language choice for Hub implementation. For  
Perl at least, it means that the Perl binary will have to be compiled  
with ithreads enabled, and while mine is, most peoples aren't. Up  
till now I've been implementing the Hub using vanilla Perl, this  
implies that you won't be able to take the Perl implementation out of  
the box.

However the real problem is that I've got no real feel for how badly  
this might affect other languages outside the core three of Java,  
Python and Perl. In my opinion this issue massively complicates an  
otherwise fairly easily implemented specification.

So at this point I'd like to suggest we implement one of two fixes to  
remove this problem:

1) Add a recieveSynchronousCall( ) method in the client.

2) Remove callAndWait( ) from the hub.

Comments?

Al.