Hi Chip, I have been looking at the Parrot code for last couple of weeks. While going through the code there were a few things that striked me. There are quite a few places where #ifdef constructs were used to define platform specific code (#ifdef WIN32).
I was thinking would it make sense to define a Parrot Platform API that all parrot ports need to implement. This is very similar to the Linux kernel source. During the build time we should be able to resolve the platform specific code and link it in the parrot executable. There are couple of advantages of this. 1. Define a clean API that new parrot ports need to implement. 2. Keeps platforms specific code out of the parrot's core logic. 3. The new ports will not introduce bugs for already working ports. I have had some discusion with Leo about this and he thought it might be a good idea to run it by you. My initial thoughts are we could include following things could be added to the Parrot Platform API: 1. File I/O. This includes sync as well as async I/O. For platforms that do not have native Async I/O support we could build an emulation of Async I/O. 2. Network I/O: This would include API for TCP, UDP and possibly SCTP (Stream control Transmission protocol). 3. Threads and Mutexes 4. Signals / Events () 5. Environment: API to read the environment variables from OS 6. Math library (we could possibly use http://www.netlib.org/fdlibm/ for platforms that support IEEE 754 floating-point arithmetic) The idea is to define a clean seperation between parrot and the platform parrot is running on. The Parrot Platform API would possibly be the interface via which the Parrot VM discovers the platform specific functionality. A good example of a simiar abstraction is the Apache Portable Runtime ( http://apr.apache.org/). This is used in the Apache HTTP Webserver. Let me know what your thoughts are. I would not mind writing up a draft PDD or doing some proof of concept work. -- Thanks, Vishal
