[BXXPwg] Whither serial and seqno?

Marshall Rose mrose+mtr.netnews@dbc.mtview.ca.us
Mon, 24 Jul 2000 10:18:05 -0700

if you want a simple way of generating serial numbers in a multithreaded
implementation, you can always just embed the channel number in the serial

alternatively, the api you use can assign serial numbers when it enters a
critical section (e.g., generating the thing that gets put on the outgoing
frame queue).

i guess my point is that there is a lot of implementation flexibility


----- Original Message -----
From: Steve Harris <sharris@primus.com>
To: <bxxpwg@lists.invisible.net>
Sent: Monday, July 24, 2000 09:57
Subject: Re: [BXXPwg] Whither serial and seqno?

> "Marshall Rose" <mrose+mtr.netnews@dbc.mtview.ca.us> writes:
> [...]
> > the next question is whether each channel should have their own serial
> > number space or whether they should be unidirectionally or
> > unique. the choice made was unidirectionally unique because it's not any
> > harder to generate than the other three and it means we don't have to
> > the channel number back on a response.
> It seems to me that it is _is_ harder to generate a number unique to
> all existing channels - arguable more so in a multi-threaded
> library. If a BXXP library exposes an interface that allows requests
> to be created on a given channel, and most of that channel's data
> structures are more or less thread-local, then there must be some
> shared table of used/available serial numbers that each channel must
> lock down to a fresh serial number. Now, it's possible to say that the
> allocation of that serial number is deferred until the first frame
> gets passed from a channel thread to a shared output thread (thinking
> of a scheme like mod_bxxp), but that's more complicated that just
> saying that each channel manages its own set of serial numbers.
> I agree that you'd have to pass the channel back along in the
> response, but that actually makes "routing" the frame easier! At
> present, you have to look up the response serial in a shared set of
> "outstanding requests" to get the channel number, again locking down
> some shared data that the output thread would likely be contending for
> as well.
> --
> Steven E. Harris
> Primus Knowledge Solutions, Inc.
> http://www.primus.com
> _______________________________________________
> BXXPwg mailing list
> BXXPwg@lists.invisible.net
> http://lists.invisible.net/mailman/listinfo/bxxpwg