Garrett D'Amore wrote: > Roland Mainz wrote: > > Garrett D'Amore wrote: > >> Dave Plauger wrote: > >>> Ivek Szczesniak wrote: > >>>> The stdio implementation in libc is among the slowest stdio > >>>> versions out there. If you want to archive better performance you > >>>> should use the stdio implementation in libast or use mmap(2). > >>>> > >>> This is an interesting implementation suggestion, but is outside the > >>> scope of PSARC because it does not affect the interfaces > >>> being proposed. We did achieve quite a speedup over the old method. > >>> We'll take another look. > >>> > >> Using libast might well incur extra PSARC oversight -- are the libast > >> interfaces public? Consolidation private? If they are *project > >> private* then you'll need to get a contract for them. Using mmap() > >> would be free of those issues, and is likely to be the fastest without > >> imposing any new interdependencies. > > > > Erm... I think it shouldn't be a problem to make the |malloc()| and > > <stdio> parts of libast "consolidation private" for use within OS/Net > > (e.g. this are the most stable APIs of libast and very unlikely to > > change) ... > > > > ... question is: How do I do that ? > > Lets find out if this is even necessary.
Erm... the question above is more generic (since we had the idea to make libast::stdio "consolidation private" several times in the past and never had the time to do it) ... ... what's the general procedure to make a "project private" API "consolidation private" ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
