Experimental Select PMC

[cotto]

tewk++ has contributed a Select PMC. While the interface solidifies, it should be considered experimental. This ticket exists to track its progress once it's been merged. (If src/pmc/select.pmc exists, it's been merged.)

[plobsing]

Replying to cotto:

tewk++ has contributed a Select PMC. While the interface solidifies, it should be considered experimental. This ticket exists to track its progress once it's been merged. (If src/pmc/select.pmc exists, it's been merged.)

Why is this being added as a core PMC? Can Parrot not operate without it? Is it expected to be used in the majority of programs? A large minority?

Every core PMC adds (albeit slightly) to the time required to start up parrot, the memory overhead consumed by parrot, and the number of long-lived GCables present. The question we've got to ask is, do we have a legitimate reason for taxing ALL Parrot users? or are we just too lazy to add a couple loadlib statements?

[cotto]

Replying to plobsing:

Replying to cotto:

tewk++ has contributed a Select PMC. While the interface solidifies, it should be considered experimental. This ticket exists to track its progress once it's been merged. (If src/pmc/select.pmc exists, it's been merged.)

Why is this being added as a core PMC? Can Parrot not operate without it? Is it expected to be used in the majority of programs? A large minority? Every core PMC adds (albeit slightly) to the time required to start up parrot, the memory overhead consumed by parrot, and the number of long-lived GCables present. The question we've got to ask is, do we have a legitimate reason for taxing ALL Parrot users? or are we just too lazy to add a couple loadlib statements?

I agree with this assessment. Thanks for switching the PMC to a dynpmc. I still would like to do another round of review on this PMC, but I won't complain if someone feels like merging it now.

[pmichaud]

Bump.

Pm

[cotto]

After looking at the Select dynpmc again, I'm not entirely impressed with the interface. It'll work, but something closer to Python's approach strikes me as better from a API design perspective.

I'm thinking of something like one or both of the following: (r_ready, w_ready, x_ready) = s.'select'(r, w, x, timeout)

s = new "Select" s.'register'(fh, "rwe") s.'register'(fh2, "re") s.'unregister'(fh3, "rwe") s.'modify'(fh4, "e") s.'select'(999)

if s.'error'() goto foo if s.'read'() goto bar

Thoughts are welcome. If this proposed interface looks good, I'll implement it. If not, I'm willing to implement an alternative suggestion. I do want to get some kind of select functionality into Parrot, but also feel like the current implementation in tewk/select has room for improvement.

[benabik]

I created a short C file to test select:  https://gist.github.com/1171339

Basically, select.t fails on OS X because it returns both file handles as ready for error. We may just want to skip that test as being platform dependent...

[jkeenan]

In addition to not building on Windows and causing new test failures on Darwin, the merge of the tewk/select branch has now broken our build with g++. I will attach the output of 'make' run with g++ used for 'cc', 'link' and 'ld'.

By way of comparison, I did a checkout of the commit immediately preceding the tewk/select branch merge in the logs. I configured with all-g++ and was able to run 'make' and  make test without incident.

"Experimental" or not, this merge has caused so many problems that it needs to be reverted ASAP.

Thank you very much.

kid51

[jkeenan]

Merge of tewk/select branch causes all-g++ build to fail

[jkeenan]

An all-g++ build on Darwin failed in much the same way as the all-g++ build on Linux posted earlier. Here's the tail of the make output:

/usr/bin/g++ -I./include -I./include/pmc -pipe -fno-common 
-Wno-long-double  -I/sw/include -I/opt/local/include -DHASATTRIBUTE_CONST 
 -DHASATTRIBUTE_DEPRECATED  -DHASATTRIBUTE_MALLOC  -DHASATTRIBUTE_NONNULL  
-DHASATTRIBUTE_NORETURN  -DHASATTRIBUTE_PURE  -DHASATTRIBUTE_UNUSED 
 -DHASATTRIBUTE_WARN_UNUSED_RESULT  -DHAS_GETTEXT -g      
-falign-functions=16 -funit-at-a-time -W -Wall -Waggregate-return 
-Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization 
-Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral 
-Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline 
-Winvalid-pch -Wmissing-braces -Wmissing-field-initializers 
-Wno-missing-format-attribute -Wmissing-include-dirs -Wmultichar 
-Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point 
-Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch 
-Wswitch-default -Wtrigraphs -Wundef -Wno-unused -Wunknown-pragmas 
-Wvariadic-macros -Wwrite-strings -fvisibility=hidden 
-Isrc/pmc -o src/pmc/filehandle.o -c src/pmc/filehandle.c
src/pmc/filehandle.c: 
  In function 'void Parrot_FileHandle_nci_setasync(parrot_interp_t*, PMC*)':
src/pmc/filehandle.c:1200: error: 
  'Parrot_io_async' was not declared in this scope
src/pmc/filehandle.c: 
  In function 'void Parrot_FileHandle_nci_setblocking(parrot_interp_t*, PMC*)':
src/pmc/filehandle.c:1228: error: 
  'Parrot_io_async' was not declared in this scope
make: *** [src/pmc/filehandle.o] Error 1

[jkeenan]

Replying to jkeenan:

In addition to not building on Windows and causing new test failures on Darwin, the merge of the tewk/select branch has now broken our build with g++. I will attach the output of 'make' run with g++ used for 'cc', 'link' and 'ld'.

NotFound++ fixed the g++ builds with 30a829d. (See, e.g.,  Smolder 22061 (Linux) or  Smolder 22063 (Darwin). But we continue to have the problem of failures in t/dynpmc/select.t on OSes other than Linux; see the latter Smolder.

Thank you very much.

kid51

[benabik]

As far as I can tell t/dynpmc/select.t is completely bogus. It uses select on file handles which behaves differently on different platforms and doesn't work at all on Windows. Depending on what manage you read, it's a completely meaningless operation. It should probably be TODO'd until replaced by a socket-based test.

[jkeenan]

The failing test in t/dynpmc/select.t was not fixed, replaced, deleted, or TODOed for Darwin in the 3.8 release. In addition, Kevin Polulak (++ serving as RM for first time) reported it was failing on Open Solaris as well.