callAndWait( ) implementation issues?

[Alasdair Allan]

Mark Taylor wrote:
> Alasdair Allan wrote:
>> 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.
>
> interesting point.  You are correct that in order to implement  
> callAndWait() the hub will need to be multithreaded/multiprocess  
> and will require some degree of non-trivial IPC (i.e. more than  
> just wait()/kill()).  Clearly this makes hub implementations in  
> strictly single-threaded languages a non-starter, but I will admit  
> that since the threading features of the language make this sort of  
> thing relatively straightforward in Java, I had not thought about  
> this as a serious burden on implementators in other languages which  
> offer multi-threading or at least access to fork().
>
>> 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.
>
> Although I haven't written serious Perl for quite some while (so  
> don't really know what I'm talking about), I am a bit surprised  
> that this sort of thing would be sufficiently difficult to require  
> a Perl compiled with non-standard options.

Not exactly difficult, just a lot easier using threads than otherwise...

> My sketchy research suggests that it ought not to be too much of a  
> stretch to implement this functionality using SysV style IPC, if  
> available (i.e. if Perl shmget() is implemented), via a module like  
> IPC::Shareable or IPC::ShareLite.

IPC::Sharable is certainly one way of doing it, although I don't  
think it ships with the Perl core I'm already using libraries that  
aren't in the Perl core so that's not a big deal. There are a couple  
of other ways to do it as well, however the easiest way of going  
about things is just (of course) to use threads. Since virtually all  
of my Perl code is threaded I was half way through implementing it  
that way when I realised that the default Perl doesn't come threaded.  
Ooops...

>> 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.
>
> I'll admit that it does complicate hub implementation, and possibly  
> limits the languages in which hubs can be implemented.  The benefit  
> is that it's easier to write clients.  Either of your suggestions  
> makes it easier to write a hub at the expense of making it harder  
> to write clients:

Agreed, it does indeed. Although having put together a couple of  
clients now, I think that while writing a SAMP client is (a little  
bit) harder than writing the equivalent Plastic client, it's not an  
order of magnitude worse.

>> Comments?
>
> My feeling about this is that the burden on hub developers for  
> implementing callAndWait() is acceptable.  Although we have  
> deliberately moved away from the PLASTIC model which (pretty much)  
> required hubs to be written in java because of the Java RMI  
> requirement, in my opinion this does not mean that we need to bend  
> over backwards to make hub implementation as easy as possible, or  
> to remove barriers to writing hubs in the widest possible variety  
> of languages.

That's fine.

> So in my opinion we should stick with the existing synchronous  
> facade built on asynchronous calls model. Other opinions?

I'm happy enough. It just occured to me that it probably hadn't been  
thought about, so should get mentioned.

Cheers,
Al.