Re: [Playerstage-users] Request from not-threaded drivers

[Toby C. <tco...@pl...>]

Any request that has -1 returned from ProcessMessage for a driver will have
a NACK sent for it automatically. So you should get these if the request is
not supported.

Toby

2009/6/28 Paul Osmialowski <new...@ki...>

> So basically, timeout is the only way to determine that request is not
> implemented?! Could work iff both sides are in the same Player
> instance, but it is not always the case. What about slow network
> connections (i.e. d-Link wifi or DSL in Poland), we can't assume how long
> it takes to get replied... Also postgis driver which is totally
> request-driven does lot of job (wkb processing, database querying) between
> receiving request and publishing ACK. We can't determine how long it can
> take (SQL server can also be on remote machine).
>
> Paul
>
> On Sun, 28 Jun 2009, Toby Collett wrote:
>
> > I was about to suggest just grabbing the code from the Request method.
> > Basically this sets a filter on the drivers queue that will not process
> any
> > other messages until the reply gets through or times out...
> >
> > Toby
> >
> > 2009/6/28 Paul Osmialowski <new...@ki...>
> >
> >> Implementing this idea isn't easy. With this PutMsg() method, how can I
> >> forward information that the driver to which I sent REQ message (using
> >> PutMsg()) does not impement given request (its ProcessMessage returns
> with
> >> -1 on it)? How it is done inside of Request() method is not clear for
> me.
> >>
> >> Paul
> >>
> >> On Sat, 27 Jun 2009, Paul Osmialowski wrote:
> >>
> >>>
> >>>
> >>> On Sat, 27 Jun 2009, Toby Collett wrote:
> >>>
> >>>> In general it is hard to guarantee that you will not get a deadlock in
> a
> >> non
> >>>> threaded driver when using the request mechanism. I have always used
> >>>> threaded drivers for this in the past. The alternative to this is to
> not
> >> use
> >>>> the 'Request' method, but rather use putmsg to send the request, and
> >> then
> >>>> process the response when it arrives as per normal messages. This
> >> however
> >>>> does require some more tracking on the drivers part to know what
> >> response is
> >>>> associated with a request and so on.
> >>>>
> >>>> Toby
> >>>>
> >>> That's what I suspected. I've changed two of the plugin drivers back to
> >>> threaded, however, I still want my goto and globalize drivers
> (previously
> >>> known as globalgoto2, now split intp two parts) to be able to forward
> >>> requests and answers on position2d interface (they both do not make
> >>> requests for themselfs, all requests are forwarded from subscribers). I
> >>> hope this putmsg mechanism would do the trick, however I need to know
> how
> >>> to prepare headers to make sure ACK/NACK replies will go to proper
> >> senders
> >>> (whenever few requesters are expecting answer).
> >>>
> >>> Paul
> >>>
> >>>> 2009/6/27 Paul Osmialowski <new...@ki...>
> >>>>
> >>>>> Hi Toby,
> >>>>>
> >>>>> Is it good idea for a not threaded driver to send requests as a
> result
> >> of
> >>>>> message processing? I've started player instance with Stage and lots
> of
> >>>>> not threaded plugins drivers (and only two threaded drivers). After
> >> some
> >>>>> time of working client messages couldn't be processed. I've also
> >> realised
> >>>>> that some of the not-threaded drivers seemed to be dead. I've put
> lots
> >> of
> >>>>> warning messages into their code and I've found that at almost the
> same
> >>>>> time two non-threaded drivers were before sending request. After a
> >>>>> while, one of them continued after receiving ACK, while other one was
> >>>>> blocked on waiting. Also "Unhandled message for driver type=resp_ack"
> >> was
> >>>>> thrown which means one of the drivers didn't process ACK for request.
> >>>>> The easiest solition (that I'm using for now and it works properly)
> is
> >> to
> >>>>> run these drivers in separate Player instance, other is to
> reimplement
> >>>>> them as threaded (what a waste, all of them are message driven with
> no
> >>>>> heavy computations involved, context switching will take more
> >> computation
> >>>>> power for them!). Or there must be added some kind of mutex before
> any
> >>>>> Request() call from non-threaded environment to avoid mutual wait for
> >>>>> ACKs.
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>>
> >>>>>
> >>
> ------------------------------------------------------------------------------
> >>>>> _______________________________________________
> >>>>> Playerstage-users mailing list
> >>>>> Pla...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> This email is intended for the addressee only and may contain
> privileged
> >>>> and/or confidential information
> >>>>
> >>>
> >>>
> >>
> ------------------------------------------------------------------------------
> >>> _______________________________________________
> >>> Playerstage-users mailing list
> >>> Pla...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
> >>>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Playerstage-users mailing list
> >> Pla...@li...
> >> https://lists.sourceforge.net/lists/listinfo/playerstage-users
> >>
> >
> >
> >
> > --
> > This email is intended for the addressee only and may contain privileged
> > and/or confidential information
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Playerstage-users mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>



-- 
This email is intended for the addressee only and may contain privileged
and/or confidential information