Synchronous calls to the same mainloop

[uwesmail2005-lkml at yahoo.de]

--- keith preston <keithpre at gmail.com> schrieb:

> On 11/10/06, uwesmail2005-lkml at yahoo.de <uwesmail2005-lkml at yahoo.de>
> wrote:
> >
> >
> > That works as long as the call doesn't go through another process:
> > Process A calls Process B which calls (synchronously) Process A
> > If you call Process B dbus-daemon-1 it's essentially your problem.
> > You want to solve it by reconstructing the callerid anew at every
> call
> 
> 
> I guess I don't see a good use case of Process A synchronously calls
> Process
> B who in the middle of the call synchronously calls Process A.   To
> me that
> seems like a programmer error, something wasn't designed right
It's not a programmer error because the programmer can't know where the
method will be called from (Process B) or what the implementation of
the method will be (Process A) or if a third Process is involved.
> (where's the
> layering?).   I'm really not focused on solving all synchronous
Layering: For instance we have a call Hal.Mount() and Hal.Mount()
needs Fstab.Read() for config. Fstab.Read() is created to make dynamic
fstab possible. That Fstab service could possibly call Hal.UUID() for
a label of a filesystem on a freshly inserted CD. And both calls are
more natural if they are programmed synchronous. And the Layering is
not violated because both calls are about different areas of
experience.
> blocking
> problems because that seems generally impossible, just the case of a
It is not impossible because Windows does it in its SendMessage()
implementation for twenty years now. It does it with a callerid
known as &MessageQueue. In DCOM the same problem was encountered and
solved the same way.
> Process
> wanting to use DBus to Synchronously call itself.
> 





	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de