New comment on block [block-idp11616480] #1701

Closed
ghost opened this Issue Jun 18, 2013 · 5 comments

Comments

Projects
None yet
2 participants
@ghost

ghost commented Jun 18, 2013

This is where the approach followed by Ctypes (and other FFIs based on similar ideas, e.g. Haskell's) breaks badly. Nowhere in the POSIX standard is this exact definition of struct timeval guaranteed. The only guarantee is that it's a struct with at least fields tv_sec and tv_usec, not necessarily in this order. A quick Google search shows this actual definition for instance:

struct timeval {

ifdef sparc64

uint32_t    __pad;

endif

time_t      tv_sec;

ifdef alpha

uint32_t    __pad;

endif

suseconds_t tv_usec;

}

This comment references this from milestone beta1: http://www.realworldocaml.org/beta1/en/html/foreign-function-interface.html#idp11616480

Context:

Let's improve the timer function that we wrote earlier. The POSIX function gettimeofday retrieves the time with microsecond resolution. The signature of gettimeofday is as follows, including the structure definitions.
Owner

avsm commented Jun 18, 2013

Agreed. We've got a couple of strategies to deal with this in upcoming versions of ctypes (/cc @yallop):

  • A configure-time check to determine the layout on the current host to determine the precise layout.
  • Generate concrete C stubs at compile-time (via an IDL similar to camlidl) from the Ctypes definition, which gives us close to the same performance as the existing FFI, but with considerably more safety guarantees about the generated stubs.
  • (longer term) a meta-programming technique to perform Ctypes expansion at runtime too.

The important feature is that the Ctypes definitions are separate from the module that invokes the call (Foreign, currently). This lets us keep defining Ctypes for more libraries, and work on the runtime side separately.

Note that I've got a half-finished chapter with the details of the normal FFI, but a full explanation blew our page budget considerably. I'm currently planning to finish the chapter post-publication and make it an online-only supplement, but could wrestle it into the current edition if you feel strongly that it's needed.

@ghost

ghost commented Jun 18, 2013

2013/6/18 Anil Madhavapeddy notifications@github.com

Note that I've got a half-finished chapter with the details of the normal
FFI, but a full explanation blew our page budget considerably. I'm
currently planning to finish the chapter post-publication and make it an
online-only supplement, but could wrestle it into the current edition if
you feel strongly that it's needed.

No, I don't think you should stronghold this extra chapter in the book.
But I'd suggest to finish chapter 20 with a mention that there is another
FFI that give more precise control on data representation and better
portability across C / OS variants, at the cost of writing significant
amounts of C code, then give pointers to the OCaml reference manual and
also to the earlier O'Reilly OCaml book, which has a whole chapter on the
basic FFI, if I remember correctly. And of course you'd add a pointer to
your online supplement when it's ready.

In other words: please don't make it look as if Ctypes is the best and the
only OCaml FFI. It is beautiful but has obviously never been used "in
anger".

On 18 Jun 2013, at 15:38, Xavier-S-Leroy notifications@github.com wrote:

In other words: please don't make it look as if Ctypes is the best and the
only OCaml FFI. It is beautiful but has obviously never been used "in
anger".

Absolutely. The only reason this pointer to the official FFI wasn't included
in beta1 is because I removed the FFI chapter quite late and didn't get a
chance to fix up the references appropriately. It'll be in beta2.

-anil

Owner

avsm commented Aug 16, 2013

Section on alternatives added to beta3, and also explanation of how to probe for struct offsets by generating C code. This hasn't been released in an official ctypes yet, but it's been committed and is being polished now.

@avsm avsm closed this Aug 16, 2013

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