From: Toby C. <tco...@pl...> - 2009-06-28 07:52:51
|
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 |