On 24 February 2010 15:45, Dag Sverre Seljebotn <[email protected]> wrote: >> 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.) >
OK. Name mangling is something to take into account, though 'api' is also related to this. > It's not made static in the C file, meaning it is possible for other C > files to link to it. > OK, but non-static does is not the same that dll_export. On Linux, with default visibility, it is; but this is not the case on Windows. And Stefan commented that this should not support the DL_EXPORT stuff. > 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" -- > Well, again, that depends on what 'public' means. > although I think > in some environments (Windows?) it is actually required to hide symbols > from the resulting shared object, so "public" can actually hurt. Here, assuming that 'public' means DL_EXPORT. Some time ago, Greg commented that DL_EXPORT (I mean, what it actually does) was not the intended meaning of 'public'. > On Linux, > Python defaults to RTLD_PRIVATE so it doesn't matter so much. > AFAIK, it is RTLD_LOCAL. However, I would not like to rely on that to prevent namespace contamination (at dynamic linker level) Greg, I would love to have some input from your side. This is something where Pyrex and Cython should agree (probably by following recommended, documented practices in core CPython). -- Lisandro Dalcin --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
