Asynchronous i/o?

[deostroll]

Hi,

I was just wondering if the modern pure c/c++ compilers have any
support for asynchronous file handling? If so in what header files are
they located in...? Any samples would be beneficial. Thanx in advance.

--deostroll

 

[jacob navia]

Hi,

I was just wondering if the modern pure c/c++ compilers have any
support for asynchronous file handling? If so in what header files are
they located in...? Any samples would be beneficial. Thanx in advance.

--deostroll

Asynchronous file i/o is supported by the OS not by the compiler. ALL
the compiler can possible do is to generate calls to APIs provided by
the operating system.

For instance under windows, the lcc-win compiler supports access to all
asynchronous i/o APIs provided by the windows OS.

To use them you should just

#include <windows.h>

You can find all the documentation about those APIs with the SDK
provided for free by Microsoft Corp.

 

[Stephen Sprunk]

I was just wondering if the modern pure c/c++ compilers have any
support for asynchronous file handling? If so in what header files are
they located in...? Any samples would be beneficial. Thanx in advance.

The C Standard does not define any asynchronous I/O functions. However,
your implementation may provide some, such as the "aio" family under
POSIX, and any reasonable compiler will let you access them. You will
have to ask in a group specific to your implementation for details,
though, since it's off-topic in clc.

S

 

[user923005]

Hi,

I was just wondering if the modern pure c/c++ compilers have any
support for asynchronous file handling? If so in what header files are
they located in...? Any samples would be beneficial. Thanx in advance.

If C++ is OK, then one solution is to use ACE:
http://www.cs.wustl.edu/~schmidt/ACE.html

Specifically:
http://www.dre.vanderbilt.edu/Doxygen/Micro/ace/a00792.html

 

[CBFalconer]

Asynchronous file i/o is supported by the OS not by the compiler.
ALL the compiler can possible do is to generate calls to APIs
provided by the operating system.

So far, OK.

For instance under windows, the lcc-win compiler supports access
to all asynchronous i/o APIs provided by the windows OS.
To use them you should just

#include <windows.h>

You can find all the documentation about those APIs with the SDK
provided for free by Microsoft Corp.

But here you are advising using components not available in C.
Standard C has no <windows.h> header file, and using it will make
the program non-portable to any non-windows system, and probably to
any non lcc-win32 compiler.

Believe it or not, there are machines and systems other than
Windows in existence. They are off-topic on c.l.c. Use a Windows
newsgroup to discuss them.

 

[robertwessel2]

Asynchronous file i/o is supported by the OS not by the compiler. ALL
the compiler can possible do is to generate calls to APIs provided by
the operating system.

I think the OP wanted to know if the standard C (or C++) library
provided access to such a thing. Not even the new C++ standard adds
AIO support, although it does add threading.

 

[deostroll]

The C Standard does not define any asynchronous I/O functions.  However,
your implementation may provide some, such as the "aio" family under
POSIX, and any reasonable compiler will let you access them.  You will
have to ask in a group specific to your implementation for details,
though, since it's off-topic in clc.

S

Does the standard have anything that lets us do "asynchronous
operations" generally speaking?

--deostroll

 

[Flash Gordon]

deostroll wrote:

Does the standard have anything that lets us do "asynchronous
operations" generally speaking?

Generally speaking, no. The closest it comes is signal handling and,
IMHO, that is not very close at all and more limited than most people think.

 

[James Kuyper]

Does the standard have anything that lets us do "asynchronous
operations" generally speaking?

Yes - it's called "undefined behavior". That's what allows the use of
non-portable implementation-specific code (such as calls to the POSIX
aio family of functions) which implements asynchronous operations.
You'll have to go to implementation-specific documentation, not the C
standard, in order to find out how to do this.

 

[Antoninus Twink]

Does the standard have anything that lets us do "asynchronous
operations" generally speaking?

Yes, the latest POSIX standard describes the aio_read(), aio_write() and
related functions.

A more traditional way of achieving this is using threads - I assume
you've already considered this and decided that the overhead would be
too great for your application. There's also good old select() or
poll(), though of course that's not /really/ asynchronous I/O.

 

[jameskuyper]

A C program with undefined behaviour is incorrect. It may behave correctly,
for instance terminating the program with an error message, or might even do
what the programmer wants, but it is not a correct program.

It is not an incorrect program if either the implementation or some
standard other than the C standard (for instance, the POSIX standard)
provides a definition of the behavior that is not defined by the C
standard. It's just not as portable as it would be if it were capable
of relying only upon the C standard's guarantees.

 

[Stephen Sprunk]

A C program with undefined behaviour is incorrect. It may behave
correctly, for instance terminating the program with an error message,
or might even do what the programmer wants, but it is not a correct
program.
Implementation-defined behaviour, however, is not incorrect. The
programmer may rely upon it if he knows the platform the program will be
compiled for.
Asynchronous operations are likely to be implementation-defined.

In terms of the C standard, many things are undefined. Other standards
(e.g. POSIX) may define those things, but as far as C is concerned,
they're still undefined -- not implementation-defined.

S

 

[CBFalconer]

Does the standard have anything that lets us do "asynchronous
operations" generally speaking?

Sure. The application just needs to be able to respond to an 'Are
you busy' call, or to send an interrupt when it goes non-busy
(operation complete). Nothing special is needed.

 

[deostroll]

Sure.  The application just needs to be able to respond to an 'Are
you busy' call, or to send an interrupt when it goes non-busy
(operation complete).  Nothing special is needed.

--
Merry Christmas, Happy Hanukah, Happy New Year
 Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
     <http://cbfalconer.home.att.net>- Hide quoted text -

- Show quoted text -

I believe the standard has provision to allow us create threads right?

--deostroll

 

[Keith Thompson]

I believe the standard has provision to allow us create threads right?

Not specifically, no. An implementation may provide threads as an
extension.

 

[CBFalconer]

I believe the standard has provision to allow us create threads
right?

Wrong. Which is why threads are off-topic here. There are groups
that deal with that.

Please snip signatures and any material not germane to your message
in your replies.