EV on AIX?

[Darin McBride]

On Friday March 23 2012 2:02:05 PM Marc Lehmann wrote:
> On Thu, Mar 22, 2012 at 04:38:39PM -0600, Darin McBride 
<darin.mcbride at shaw.ca> wrote:
> > uname -p reports "powerpc".  I see that present, but maybe you require
> > gcc.
> > Since this is largely an IBM shop, I have xlC available for use.
> 
> ecb.h has no provisions for memory fences with xlC - somebody with knowledge
> would first have to port it to xlC.

How about someone without knowledge? :-)  I did a bit of googling, tried some 
things out, and got it to compile.  And then "make test" worked, though I 
don't know how much of this memory fence stuff is tested by the current test 
suite.

diff -ur a/libev/ev.c b/libev/ev.c
--- a/libev/ev.c        2012-02-04 14:09:52.000000000 -0500
+++ b/libev/ev.c        2012-03-23 10:48:40.000000000 -0400
@@ -601,6 +601,8 @@
      #define ECB_MEMORY_FENCE         __machine_rw_barrier ()
      #define ECB_MEMORY_FENCE_ACQUIRE __machine_r_barrier  ()
      #define ECB_MEMORY_FENCE_RELEASE __machine_w_barrier  ()
+   #elif __xlC__
+     # define ECB_MEMORY_FENCE       __lwsync ()
    #endif
  #endif


>From http://peeterjoot.wordpress.com/2010/06/07/a-nice-simple-example-of-a-
memory-barrier-requirement/ (Though I found this via google, I actually know 
the author IRL, and he does seem to be a genius).  The only issue is that 
Peeter claimed that this function was in builtins.h, but I can't find that on 
my AIX box.  I'll have to ask him about it.  (It doesn't seem to be required.)

> > > Easier would be to use a non-antique gcc version (e.g. 4.4), which
> > > should
> > > have the relevant memory fences built-in, or llvm/clang.
> > 
> > I bet xlC is considered antique :-)  (Looks like xlC 10.1.0.2, but that's
> > probably not important.)
> 
> xlC is... not just considered antrique, it is one of those few vendor
> compilers where I have vivid memories of - not positive ones :)

Yeah, I get that a lot.  I'm compiling perl 5.15.9 on it, which more or less 
works, but a lot of module authors assume that using "//" in C code works fine.  
Which it does with modern gcc compilers, but xlC's defaults don't allow that.  
Yes, I know, that's from the 1999 standard of C.  I've not known anyone to 
accuse IBM of being quick on the uptake on too many things (Linux itself might 
be, relatively speaking, an exception).

(I've already seen that you're aware of how 5.15.9 and common::sense don't see 
eye-to-eye under -w, which is, quite unfortunately, how tests are run.)

> But that's not the point - I specifically meant gcc - a reasonably current
> gcc version has support for memory fences that libev can pick up.

I kind of got the impression that you meant gcc.  Perhaps the above patch will 
at least allow xlC to be used :-)

> > > Any event loop you like and can get compiled, I guess.
> > 
> > Makes sense :-)  I just know that you have some recommendations in the AE
> > docs, but wasn't entirely sure how big of a deal it is.
> 
> Well, personally, I'd go for EV, and if that isn't available, and
> otherwise I don't care much.

Fair enough.

> > > So, using the pure perl event loop on aix is definitely an option that
> > > shouldn't lose out much.
> > 
> > Fair enough.  I won't worry about it too much, then, since I have more CPU
> > power than I need, and likely far too much RAM as well, since when I'm
> > running, usually nothing else is (and vice versa - when I'm not running,
> > usually *everything* else is).  Thanks!
> 
> Well, given the memory hog that perl in general is (tiny stuff such as
> Digest::MD5 comes ion at 1MB ram on my box, even something as trivial as
> use strict uses 275kb here), *that* extra memory is unlikely to become an
> issue :(

That's generally my perspective.  If I wanted to quibble about a MB of RAM 
here and there, I'd be using C.  And I don't use C.  (I'd use C++, but there 
goes huge swaths of memory savings, too.  More if I ever get around to 
learning wx or Qt or some such behemoth.)