> On Feb 24, 2010, at 6:41 AM, Lisandro Dalcin wrote: > >> On 24 February 2010 03:24, Robert Bradshaw <[email protected] >> > wrote: >>> On Feb 23, 2010, at 7:13 AM, Lisandro Dalcin wrote: >>> >>>> Bump! >>>> >>>> On 18 February 2010 04:27, Stefan Behnel <[email protected]> >>>> wrote: >>>>> Lisandro Dalcin, 17.02.2010 23:38: >>>>>> What is not clear to me is the following: Should "public", >>>>>> "api", or >>>>>> "public api" have any semantic diference? >>>>>> [...] >>>>>> Greg said that he never intended to provide DLL export >>>>>> mechanisms, and in fact he just wanted to make stuff available >>>>>> across >>>>>> compilation units (i.e, make stuff available to other C source >>>>>> files >>>>>> being compiled ALONGSIDE the generated C sources to build the >>>>>> final >>>>>> ext module). If we enforce this, I mean we are not going to >>>>>> support >>>>>> ext module interlinking, then almost the usages of DL_IMPORT/ >>>>>> DL_EXPORT >>>>>> macros are a nonsense and should be removed, alongside almost all >>>>>> these dll_linkage arguments in many methods. >>>>>> [...] >>>>>> So... What do you think? >>>>> >>>>> My take is that public symbols are only portably usable at static >>>>> link >>>>> time, so supporting more is simply not worth it. Even static >>>>> linking >>>>> against symbols exported by a Cython module should be a very rare >>>>> use case. >>>>> It's not used when calling external C code nor is it worth anything >>>>> when >>>>> providing callbacks into the Cython code. Most of the time, the >>>>> external >>>>> code will be there first and will be used by the Cython code, not >>>>> the other >>>>> way round. This mechanism shouldn't be seen as something that's >>>>> usable at >>>>> dynamic linking time. There's public C-API support for that. I >>>>> second your >>>>> intuition that the DL_EXPORT stuff can be dropped completely. >>>>> >>>> >>>> OK. >>>> >>>>> There's also the use case of statically linking multiple Cython >>>>> modules >>>>> into one extension module. This isn't currently supported (really), >>>>> and >>>>> there's more to do to make it run smooth. >>>> >>>> Are you talking about the limitations/gotchas in Python's import.c >>>> implementation ? >>>> >>>>> But I don't think it would >>>>> interfere with the above in any way. >>>>> >>>> >>>> Of course. >>>> >>>> Anyone has something to add? Greg? >>>> >>>> Still... What should we do with 'public' and 'api' keywords? >>> >>> I don't really use either, so while I agree that it would be nice to >>> clean things up, I don't want to break backwards compatibility. >>> (Judging from the lack of activity on this thread though, it seems >>> they're not in high demand, though sage-support should be pinged if >>> we >>> plan on getting rid of anything.) 'public' should probably still mean >>> what it always has. >>> >> >> Could you explain me the exact meaning of 'public' (alone, without >> 'api')? > > Doesn't it simply avoid mangling names? (It may have other side > effects as well.)
It's not made static in the C file, meaning it is possible for other C files to link to it. If module A has a public function, and one sets sys.setldopenflags (or something like that) to RTLD_GLOBAL, then one should be able to load another module B which depend on a symbol in A provided A is imported first. Perhaps this is marginally faster than using function pointers. I'd argue that one simply makes "api" imply "public" -- although I think in some environments (Windows?) it is actually required to hide symbols from the resulting shared object, so "public" can actually hurt. On Linux, Python defaults to RTLD_PRIVATE so it doesn't matter so much. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
