logo       

Sponsor
FREE Network Mapping Tool for Microsoft® Office Visio® Professional 2007
Don't map your network by hand - let LANsurveyor Exx press for Microsoft Visio Professional 2007 automatically create network diagrams for you!

Re: callback-based reply handling: msg#00060

freedesktop.xcb

Subject: Re: callback-based reply handling

On Mon, Apr 11, 2005 at 01:00:33AM -0700, Barton C Massey wrote:
> In message <20050410212138.GY24279-sH+B+fTmh7PR7s880joybQ@xxxxxxxxxxxxxxxx>
> you wrote:
> > To implement the polling support, I had to add a new public function to
> > XCB: XCBGetRequestRead returns the last sequence number that the server
> > is known to have processed. This sequence number can be compared to the
> > one in a reply cookie to determine whether forcing the cookie would
> > block. (Requests with multiple replies might still block, but probably
> > not for very long...) I'm not sure that this function will remain as-is:
> > getting the test for "would-block" right is tricky in the face of 32-bit
> > sequence number wraps, and maybe we just want a function that answers
> > the "would-block" question. The function I implemented, though, should
> > be useful in Xlib, while the "would-block" function might not be.
>
> Do both, unless some reason not to.

I had just about talked myself into doing both, yeah. OK. :-)

> We've talked about having "would-block" forever; I forget why it
> wasn't already added.

I think we couldn't see why anyone would want it, but as always I might
not be remembering correctly. If that was it, the problem is taken care
of now. :-)

> > If you use the reply thread mechanism, you'll get the best results if
> > you can ensure that reply cookies are added in order of sequence number.
> > (This is easy to ensure for a ReplyHandlers structure that has all its
> > cookies added to it by the same thread.) If cookies are added out of
> > order, some might get deferred until a later reply is processed:
> > presumably not fatal, but more delay than necessary.
>
> Some reason not to keep the internal queue as a PQ on
> request sequence number? Probably :-).

Nope, no reason not to. :-) Doesn't help though. At the moment I'm using
a sorted linked list for easy implementation, which (I should hope) is
equivalent.

The problem is that an item could be added to the list while the
reply-handling thread is blocked inside XCB, waiting for a later reply.
I dunno how to wake it up and make it come back to the earlier one, or
how to efficiently ensure that XCB never blocks.

--Jamey





Only community members can participate in forum threads. You must Register or log in to contribute.

<Prev in Thread] Current Thread [Next in Thread>
Sponsor
FREE Network Mapping Tool for Microsoft® OfficeVisio Professional 2007
Don't map your network by hand - let LANsurveyor Express for Microsoft Visio Professional 2007
automatically create network diagrams for you!
Google Custom Search

Free Magazines

Cisco News
Receive a free quarterly e-newsletter with exclusive articles on how Cisco IT uses its own products and solutions to enable the business.
subscribe

Systems Management News, the newspaper for IT systems administration and data center managers! Each issue of Systems Management News is chock-full of news and analysis to help you understand what's happening in your field.
subscribe

The Enterprise Newsweekly eWeek is the essential technology information source for builders of e-business.
subscribe

Oracle Magazine Oracle Magazine contains technology strategy articles, sample code, tips, Oracle and partner news, how to articles for developers and DBAs, and more. Oracle (NASDAQ: ORCL) is the world's largest enterprise software company.
subscribe

Total Telecom Total Telecom is "The Economist of the communications industry".
subscribe

Navigation

Home | sitemap | advertise | OSDir is an inevitable website. super tiny logo