EV on AIX?

Darin McBride darin.mcbride at shaw.ca
Sun Apr 29 07:41:12 CEST 2012


On Sunday April 29 2012 1:57:00 AM Marc Lehmann wrote:
> On Sat, Apr 28, 2012 at 08:02:21AM -0600, Darin McBride 
<darin.mcbride at shaw.ca> wrote:
> > On Saturday April 28 2012 2:24:45 PM Marc Lehmann wrote:
> > > On Thu, Apr 26, 2012 at 12:28:07PM -0600, Darin McBride
> > > Hmm, I am not aware of any fix needed for aix at the moment, and I don't
> > > really get anything out of the quote either, which fix do you mean? You
> > > mean xlC thread support?
> > 
> > I mean the one that is in your cvs for libev with the entry in the Changes
> > 
> > file:
> >       - (ecb) add memory fence support for xlC (Darin McBride).
> 
> Hmm, that dds support for xlC, it doesn't really fix anything.

It fixes this:

"libev/ev.c", line 941.3: 1506-205 (S) #error "memory fences not defined for 
your architecture, please report"

> > > Looking at the old thread, there are lots of feasible workarounds
> > 
> > You mean using -DECB_NO_SMP or -DEV_NO_THREADS?
> 
> Or using gcc, or pthreads.

GCC requires a fix similar to the lawyer fix, except this one is for management.  
We have a fully licensed xlC build system, we're expected to use it and not 
use gcc, at least on AIX.

As for pthreads, perl -V says:

    cccdlflags=' ', lddlflags='-b64 -bhalt:4 -G -bI:$(PERL_INC)/perl.exp -bE:
$(BASEEXT).exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib'

So it seems that I should be using pthreads already.  And ldd confirms:

$ ldd /opt/darin/perl5_64/bin/perl | grep pthread
         /usr/lib/libpthreads.a(shr_xpg5_64.o)

So simply using pthreads is not sufficient.

> > especially considering there is a fix in your cvs that just simply hasn't
> > been
> Except it doesn't fix anything, certainly not the problem you have.

If I apply said patch, the problem I have goes away.  Well, the technical one.  
The lawyer problem ratchets up.

> > > Well, the soltuion for not wanting to patch would be to not patch. Also,
> > > your problem with your legal department seems to be a problem with your
> > > legal department, and the solution would be to solve that problem - a
> > > release of libev will not fix any legal or procedural issues.
> > 
> > Sure it will.
> 
> Simply insisting on this does not make it so. Again, you have a problem,
> and it's with your legal department. A libev release cannot fix this
> problem. Postpone it maybe, hide it maybe, but the problem will not go
> away.

Sure, I still have to go through legal for everything else.  But one question 
they ask is "will you be modifying the source" and if I say "yes", then they 
will bring much more scrutiny because then I could be "tainting" proprietary 
code with open-source code by spending time looking at the code.  After the 
SCO vs IBM lawsuit, there's a desire to keep as much barrier between OSS code 
and proprietary code as possible.

"Simply insisting" that my employer's lawyers are a problem doesn't help the 
problem.

> > but this is all relative.  They don't like us patching code for shipment
> > because they think that opens us up to something legal.
> 
> You still don't have to patch code for that.

I'm sorry, I'm not following.  You have a fix in cvs that, if it should be 
released before I go to the lawyers, would reduce my interrogations by said 
lawyers, should I wish to simply use the defaults (which would definitely be 
easier).  All I asked at the outset here is if you were planning on making an 
official release of EV that included said fix in the near future.  Actually, I 
asked what timeline you were planning on for that release.  I'm only asking if 
you have plans for "this week" vs "this month" vs "some time from now, maybe a 
few months, maybe more" or what.  I don't need assistance telling me how 
screwed up the legal requirements are, I've been telling that to various 
managers for two years now.  While working to improve things, I still have to 
work within the existing framework until then.



More information about the anyevent mailing list