[Asterisk-Dev] Race issue in channel.c involving uniqueint on Asterisk 1.2.1

[Luigi Rizzo]

On Mon, Jan 02, 2006 at 04:57:20PM -0600, Tilghman Lesher wrote:
> On Monday 02 January 2006 02:31, Dinesh Nair wrote:
> > On 12/30/05 23:02 Tilghman Lesher said the following:
> > > On Friday 30 December 2005 07:12, Luigi Rizzo wrote:
> > >>I think the proper course of action is to wrap the atomic ops
> > >>into macros, and then let the common header implement the
> > >>locking in the proper way, with fallback to the above
> > >>sequence only for unknown architectures.
> > >>
> > >>FreeBSD (and i suppose linux as well) has example code
> > >>for i386 and others in the machine/atomic.[ch] files
> > >
> > > This appears to be FreeBSD-specific (or BSD-specific).  There are
> > > no such macros on Linux.
> >
> > but as luigi pointed out, these are architecture specific, so with
> > linux also being used on the x86 class of processors, porting these
> > freebsd constructs over shouldnt be too difficult. or so i think.
> 
> Patches are welcome on http://bugs.digium.com

This is an architectural decision. If it is not considered
interesting, patches are useless, a waste of time on my side,
and clutter on mantis.

And speaking as one who, according to mantis, has submitted 67
reports to date, 57 of which with patches; and has done the
'waste-of-time' exercise several times, with a number of architectural
proposals, some of which requiring a lot of work, which have been
sitting there, not even reviewed (e.g.  4377, 4584, 5675) and a
number not even submitted because interfering with the pending ones,
you will see that 'patches are welcome' is not exactly a good
argument here...

"i think luigi is wrong because ...." would be a much better argument;
even better would be "i think luigi is right", but one can't always be right :)

	cheers
	luigi