platform independent non-blocking io

Maybe ACE will be useful for you, it is good, but rather big and compilicated (as any good product)

http://www.cs.wustl.edu/~schmidt/ACE.html

thanx for the quick response. u r rite abt ACE, it's huge and quite overwhelming at first look ... and will take more time to accomplish what i intend...

i am looking for a small and simple solution. currently i'm using the select function in UNIX checking for input from stdin... that's lite weight enough but won't run correctly on win32 which implements select differently (in UNIX everything is a file so it's easier but not in NT or win98)..

>> Is there any readily available function that provides non-blocking io
>> that can be used for codes that will be compiled across multiple platform
considering the fact that some platforms are incapable of performing non-blocking i/O, the answer has to be no.   (I.e. teletype or a dumb terminal).

The curses library is capable of performing non-blocking I/O on unix, on platforms that are able to support it.   There might be versions ported to windows.

For sinple needs, like yours sound like, it can often be handled by writting 1 or 2 custom I/O functions whose contents are Os-specific and controled by conditional compilation (#ifdef...#endif).

You can use POSIX 1003.1 Signal Functions such as sigprocmask()
#include <signal.h>
int sigprocmask(
          int how,
          const sigset_t *set,
          sigset_t *o_set);

POSIX functions are platform independent functions, however, to the best of my knowledge, windows does not currently support most of the POSIX functions.

Unix and Linux do support POSIX functions.

>> POSIX functions are platform independent functions, however, to the
>> best of my knowledge, windows does
>> not currently support most of the POSIX functions.
If it is platform independant why doesn't Windows support it?  Why doesn't Macintosh?  VMS?  etc.

POSIX is a UNIX standard.  LINIX supports it because of its UNIX roots.  Those are the only OSs that I know that support it.

If we are talking about non-blocking IO, then it is mainly select. Windows does have select, but
a) IMHO it has different signature, because socket is different from file handler (on UNIX platforms they are the same)
b) Microsoft discourage its usage, it proposes to use WSASelect.


jarod, if you need something more or less simple, you can create class hierarchy with one root class and two child classes for Windows and POSIX compliant systems.
It should not be too difficult. Just look at UNIX and windows sample programs

>>If it is platform independant why doesn't Windows
>>support it?  
You can compile code in Windows using POSIX functions.
I got the following link from jkr:
http://www.redhat.com/products/tools/cygwin/

Cygwin allows you to use POSIX functions in Windows.

>>POSIX is a UNIX standard.  
POSIX has unix roots, but so does C++.

POSIX stands for "Portable Operating System Interface for Computing Environments".
It was published as an American National Standard.
In 1990, IEEE Std 1003.1-1900 was published as an International Standard.  POSIX defines a standard way for an application program to obtain basic services from the operating system.

>> You can compile code in Windows using POSIX functions.
Well that is 3 OSs.  There are 100s more.  

>> >>POSIX is a UNIX standard.  
>> POSIX has unix roots, but so does C++.
so?  I still can't use UNIX OS calls in C++ on a non UNIX system.  If I buld a car in an air-conditioned factory, does it mean car always has to have  air-conditioning?

>> POSIX stands for "Portable Operating System Interface
>> for Computing Environments".
its a standard suggested for OS developers to conform to.   That doesn't meant that all OSs or even most OSs conform to it.  In fact, the vast majority don't.  Since it is based on UNIX, most new UNIX OSs do conform and most non-UNIX  OSs don't.

It won't work on Windows unless you use interface libraries because Windows doesn't conform.  The same is trye for the Mac OS, VMS, OS2, etc

nietod,
>>That doesn't meant that all OSs or even most OSs conform
>>to it.
I never said that all OS supports POSIX.  In fact, I went out of my way to make it clear that I didn't think Windows support it, although I now know it can support it.

I only said that POSIX provides platform independent functions.

POSIX comforming code allows you to port the code from one POSIX-conforming OS to another POSIX-conforming OS.

If you need further explanation, please post your own question.
I don't want to waste the questioner's question, on your question.

Thank you

jarod,
>>compiled across multiple platform (unix, linux, win32) ?

If you're only concern about porting your code to Unix, Linux, and Win32 platforms, then you can use the POSIX function in your code for your requirement.
You'll need to use Cygwin for the Win32 platform.  Unix and Linux should already have the required libraries to support POSIX functions.

>> I only said that POSIX provides platform independent functions.
but its not platform independant.  Ideally it would be, but realistcally its very platform depen.dant.

>> If you're only concern about porting your code to Unix, Linux, and Win32
>> platforms, then you can use the POSIX function in your code for your
>> requirement.
that I can agree with, but in that case your best bet might be conditional compilation---depending on your needs.

FYI,
According to the VC++ documentation, Windows NT has some type of support for POSIX programs via "POSIX subsystem"
However, it only supports POSIX 1003.1

>>but its not platform independent.  
It's clear that we interpret platform-independent to mean two different things.
I consider POSIX to be platform independent because POSIX code does not require a specific platform for the code to work.
That is what I mean by platform-independent.

Not all platforms support C++, but C++ is still considered a platform independent language.

I didn't know there was any official support other than what got picked up as windows was developed in it somewhat haphazard way.  (there are still elements of CP/M, much less DOS and UNIX in windows.)

>>I didn't know there was any official support other than
>>what got picked up as windows was developed in it
>>somewhat haphazard way.  

Hmmm....  Is this your way of saying your were wrong???

>> Is this your way of saying your were wrong???
Maybe wrong that its not portable to windows.  Although the docs are very unclear as to what it supports.  It doesn't appear to be complete support.

But certainly not wrong POSIX's platform indepance.  its as universal as the pesos.

>>Maybe wrong that its not portable to windows.
Wow!!  You scared me for a minute there.  I thought for a minute that you actually were going to say that you were WRONG.  In which case, hell would have freeze over, pigs would fly, and the civilization as we know it, would come to an end.
Please don't scare me like that again.  (LOL)

>>But certainly not wrong POSIX's platform indepance.  its
>>as universal as the pesos.
So are you also saying that C++ is not platform independent?

>>  thought for a minute that you actually were going to say
>> that you were WRONG.  
I've said that I'm wrong many times.  Including beign wrong in two questions today.   However, I can't tell for sure just how much windows supports POSIX.  Its only NT and later first of all, not straight win32.  but its not clear if the support is really adequite.   They do mention functions and features that are not supported.  I can't say how significant that is.  But clearly the support is not perfect.  

>> So are you also saying that C++ is not platform independent?
The C++ standard itself says that it is not.  It requires that a platform have specific features that are not true of all platforms.  

and Note that this is a very different type of portability.  When we talk about C++ portability we are talking about source code being able to compile on any conforming compiler on any platform.   If a platform does not have a C++ compiler or cross-compiler that is not a case of C++ you cannot claim that this is an issue of incompatibility.  The language is portable to compilers, not OSs.  However if you have an OS that doeesn't support the features of POSIX, or any other standard, that is a portability issue, since you can't reasonably write an OS for a platform, although theoretically you can write a compiler for it.

thanx to all those who replied to this question. i appreciate all ur effort. i think more details is needed on this question for a more concise answer.

limit platforms to the following..
1. with POSIX in mind, platform needed are all the Unix version from different provider (eg. hp, ibm, etc..). this includes linux as well.
2. i'm running cygwin for win32 (NT4 and win9x).

what i really need is a non-blocking way to detect keyboard press that can compile in the platforms mentioned above.

the following are my own opinion...
1. the c++ language itself is platform independent since it describes the functionality and not how it is implemented. therefore different compiler might implement thing differently causing incompatibility.
2. ANSI defined a set of compatible libraries which are also only description and not implementation. it is left to the implementor to decide.
3. some OSes provide additional libraries which are not guaranteed to be platform independent since it's for use on the OS itself.
4. POSIX describes functions that POSIX compatible OSes should have but not the implementation. again it's left to the implementor.

>> what i really need is a non-blocking way to detect keyboard press
>> that can compile in the platforms mentioned above.
I would suggest you use conditional compilation to write a procedure or two that allows you to this.   the unix version of the procedure can use the curses.h library to obtain the key press and the windows version can use win32 console API functions (WaitForSingleObject() on standard input)

>> 1. the c++ language itself is platform independent since it
>> describes the functionality and not how it is implemented.
>> therefore different compiler might implement thing differently
>> causing incompatibility.
Yes, but it can only run on platforms that meets its requirements.  like for instance a platform that stores only floating point numbers in memory would not be sufficient--though certainly they exist.

>>what i really need is a non-blocking way to detect
>>keyboard press that can compile in the platforms
>>mentioned above.
Just out of curiosity, why are you trying to do this in a non-blocking method?
Is it for the purpose of making a getch() equivalent method?

i have a function which continuously print information on screen which i would like to terminate when it detects a key press ... so a blocking io function will not work since it will distrupt the printing loop ...

in simple pseudo-code form it will look like ...

while true
    print what ever info
    if keypress
        break out of loop
end while

thanx for all your answers. thanx nietod for all your efforts in answering my question.