Skip to content
This repository was archived by the owner on Oct 12, 2022. It is now read-only.
/ druntime Public archive

Conversation

@Darredevil
Copy link
Contributor

@Darredevil Darredevil commented Feb 3, 2018

Added interface for posix aio in D (only for linux x64 for now).
The aiocb struct can have various implementations, for linux x64 I tested the following in C and created the equivalent in D:

C aiocb
Sizeof aiocb: 168 bytes
Offsets:
aiocb.aio_fildes:	 0
aiocb.aio_lio_opcode:	 4
aiocb.aio_reqprio:	 8
aiocb.aio_buf:		 16
aiocb.aio_nbytes:	 24
aiocb.aio_sigevent:	 32
aiocb.aio_offset:	 128

@dlang-bot
Copy link
Contributor

dlang-bot commented Feb 3, 2018

Thanks for your pull request and interest in making D better, @Darredevil! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

* D header file to interface with the Linux aio API (http://man7.org/linux/man-pages/man7/aio.7.html).
* Available since Linux 2.6
*
* Copyright: Copyright Alexandru Razvan Caciulescu 2018.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

D Language Foundation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took core.sys.linux.epoll as an example for the copyright, is that file not respecting the convention?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That file was written long before the DFL existed. We can't easily change the copyright for existing modules, but we can for new additions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed


private import core.sys.posix.signal;

version (linux):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CRuntime_Glibc, not linux.

ubyte[24] internal_members_padding;
off_t aio_offset;
ubyte[32] __glibc_reserved;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra space

@@ -0,0 +1,66 @@
/**
* D header file to interface with the Linux aio API (http://man7.org/linux/man-pages/man7/aio.7.html).
* Available since Linux 2.6
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this should be in core/sys/linux then, not posix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually no, there are two instance of AIO, the POSIX aio (aio_* family) and Linux libaio.
I believe this is in the correct place.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is POSIX AIO interface except for aio_init I think.

@andralex
Copy link
Member

@ibuclaw good to go?

@CyberShadow can you please advise regarding the merge error in circleci?

@wilzbach
Copy link
Contributor

Can you please advise regarding the merge error in circleci?

@Darredevil's fork was pretty outdated and we upgraded to CircleCi 2.0.
tl;dr: rebasing helps. I just did so.

@Darredevil
Copy link
Contributor Author

@ibuclaw all looks good now

@@ -0,0 +1,65 @@
/**
* D header file to interface with the Linux aio API (http://man7.org/linux/man-pages/man7/aio.7.html).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any link to the posix standard that is not a Linux manpage?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made the change myself. All, feel free to operate noncontroversial changes (spacing, better links) right on the spot - it takes only a bit longer than making the request and accelerates the cycle greatly.

Copy link
Member

@andralex andralex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ibuclaw good to go?

@@ -0,0 +1,65 @@
/**
* D header file to interface with the Linux aio API (http://man7.org/linux/man-pages/man7/aio.7.html).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made the change myself. All, feel free to operate noncontroversial changes (spacing, better links) right on the spot - it takes only a bit longer than making the request and accelerates the cycle greatly.

Copy link
Member

@ibuclaw ibuclaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nits and C compatibly problems.

int aio_read(aiocb *aiocbp);
int aio_write(aiocb *aiocbp);
int aio_fsync(int op, aiocb *aiocbp);
int aio_error(aiocb *aiocbp);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const(aiocb)*?

int aio_fsync(int op, aiocb *aiocbp);
int aio_error(aiocb *aiocbp);
ssize_t aio_return(aiocb *aiocbp);
int aio_suspend(aiocb*[] aiocb_list, int nitems, timespec *timeout);
Copy link
Member

@ibuclaw ibuclaw Feb 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First parameter would not be the equivalent D type you're looking for. The closest approximation would be aiocb**.

Also could have const(aiocb*)* and const(timespec)*

ssize_t aio_return(aiocb *aiocbp);
int aio_suspend(aiocb*[] aiocb_list, int nitems, timespec *timeout);
int aio_cancel(int fd, aiocb *aiocbp);
int lio_listio(int mode, aiocb*[] aiocb_list, int nitems, sigevent *sevp);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aiocb*[] would be a dynamic array, so this should be instead const(aiocb*)*


private import core.sys.posix.signal;

version (CRuntime_Glibc):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Top of file should be guarded with version (Posix), not glibc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea is that this has only been tested on linux/Glibc so far, of all Posix platforms.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't mean we should drop the convention used in every other sys/posix module. New modules that require porting should come with big alarm bells to notify those working on said unsupported platforms to check this code very carefully.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, your edit suggestions look good.

private import core.sys.posix.signal;

version (CRuntime_Glibc):
version (X86_64):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be here, rather it should be moved to where x86_64-specific definitions are.


ubyte[24] internal_members_padding;
off_t aio_offset;
ubyte[32] __glibc_reserved;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like the only platform specific part of this module here. Make a porters life easy and guard it properly with appropriate version blocks and static asserts.

i.e:

version (CRuntime_Glibc)
{
    version (X86_64)
    {
        struct aiocb
        {
            //... 
        }
    }
    else
        static assert(0);
}
else
    static assert(false, "Unsupported platform");

/**
* D header file to interface with the
* $(HTTP pubs.opengroup.org/onlinepubs/9699919799/basedefs/aio.h.html, Linux aio API).
* Available since Linux 2.6
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't you have dropped the Linux references here?

Take a look any of the other core.sys.posix module headers, eg: https://github.com/dlang/druntime/blob/master/src/core/sys/posix/pwd.d

@Darredevil
Copy link
Contributor Author

@ibuclaw thanks for the suggestions, updated accordingly

@@ -0,0 +1,74 @@
/**
* D header file to interface with the
* $(HTTP pubs.opengroup.org/onlinepubs/9699919799/basedefs/aio.h.html, Linux aio API).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd still say Posix AIO here, as I've repeatedly said, this is not a linux module. ;-)

@ibuclaw
Copy link
Member

ibuclaw commented Mar 3, 2018

@Darredevil - I think just one last nit and then I'll shut up.

@Darredevil
Copy link
Contributor Author

@ibuclaw should be good to go now

@ibuclaw
Copy link
Member

ibuclaw commented Mar 3, 2018

Ping @joakim-noah @redstar @yshui @dkgroot @rracariu

FYI this module is in dire need of porting. ALL PLATFORMS WILL FTBFS until this is fixed.

@joakim-noah
Copy link
Contributor

Not a big deal, none of our platforms are tested with this master branch, if at all. Once it moves downstream, we'll test and fix it.

@ibuclaw
Copy link
Member

ibuclaw commented Mar 3, 2018

@joakim-noah - Yeah, depends how you build druntime also. As a litmus test, all druntime modules are built in gdc's tree regardless of compiler target. This ensures that at least -fsyntax-only passes on all platforms.

@dkgroot
Copy link
Contributor

dkgroot commented Mar 3, 2018

How about adding some unittests, that would ease porting to other platforms.
example posix aio conformance tests (in c):
http://repo.or.cz/ltp-debian.git/tree/HEAD:/testcases/open_posix_testsuite/conformance/interfaces.

The linux implementation of posix_aio is (mostly) oriented toward async non-blocking (raw) file i/o. I am not 100% sure if i remember correctly, but using it with sockets was not supported on linux (?). On other platforms posix_aio can also be used to deal with sockets (though not often used as far as i know). Should the orientation toward file i/o be noted, or should using a socket FD not be permitted for example ?

@ibuclaw
Copy link
Member

ibuclaw commented Mar 3, 2018

How about adding some unittests, that would ease porting to other platforms.

That's never really been done for other modules, and I can think of a few where there's good reason for that as well. Be it math functions that return a different result depending on the platform, or format functions where format specifiers may not exist on older systems.

In any case, I don't think its our role to test the C runtime library here, and there's too many variations between them to really be useful, and these libraries have their own testsuite anyways. ;-)

Of course, if there's something we implement, then that needs a unittest.

@dkgroot
Copy link
Contributor

dkgroot commented Mar 3, 2018

@ibuclaw i was not looking to test the c-implementation, to to check that we present the same results on all platforms. But ok, if that is not something we normally do. I assume that once there is a phobos library using this, it would be unittested there.
I will look into porting to freebsd and dragonfly when this part is merged. Should be pretty straight forward.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants