Boost logo

Boost :

From: Jarl Lindrud (jlindrud_at_[hidden])
Date: 2005-03-08 10:20:29

Scott Woods <scottw <at>> writes:
> Hi Jarl,
> I have browsed your CodeProject materials and followed this thread with
> interest. The project was familiar but with the pertinent magazine no longer
> in my
> possession, I cannot give you the proper acknowledgements. Was that your
> work in CUJ?

No, but I think I remember the article you're referring to, in fact here it is:

I haven't really looked at it, but in some ways it's quite similar.

> To cut a long story short, I believe what is really needed is a "signaling"
> or
> "messaging" library. Construction of an RPC facillity over the top of such
> a library would be perfectly valid. The "sub-optimal" thinking I mentioned
> earlier is my term for a development environment where RPC is considered
> the basic building block for distributed computing.


> If this message is useful to you maybe its to help decompose the design
> and implementation of RPC. If the internals of your RPC were totally
> message-based and state-driven then perhaps everyone would be
> happy. Well, I would be
> Cheers,
> Scott

Thanks for the comments Scott,

You have some good points.

I agree with you that its poor style to have a client block while waiting for a
reply. In fact, blocking functions are almost always poor style, whether you're
dealing with network communications or anything else.

Someone mentioned previously in this thread as well, that it would be unwise to
place remote function calls behind local function call semantics. If the remote
call is blocking, then I agree, but the problem is that the call blocks, not
that it's a remote call looking like a local one.

I'm pretty sure I can make my library function well both in non-blocking and
blocking modes, but it needs to be designed from the bottom up, with that in
mind, as you're saying. I'm going to be redesigning it anyway, so hopefully
there will be some opportunity to get it right.


Boost list run by bdawes at, gregod at, cpdaniel at, john at