This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 2.3 plans


> I still hope to get the thread-library rewritten but this won't happen
> in 2.3.

I hope that before this does start to happen, whenever that is, you let us
here know about your implementation ideas in detail, early and often.
There are a few volunteers interested in working on pthreads for Hurd.
It's important to me that their efforts be integrated well with yours and
that we end up with a threads library that is both very well-integrated
into libc and cleanly portable (i.e. machine dependencies are well isolated
from OS dependencies, individual implementation choices are modular, etc).
When this does take shape, we will hopefully also rewrite the Hurd signals
code in libc to integrate properly with pthreads and to implement the full
1003.1-1996 signal semantics.  If this all comes together in 2.4, that will
be a fine fine thing.

> - implement read-only mmap() support for streams; read-only streams should
>   under certain circumstances simply use one mmap() call and set the
>   buffer pointers appropriately

Does "Later" in your list mean that you now don't plan this for 2.3?  This
is something that I'd planned to implement from the beginning in GNU stdio.
But I was always concerned about the problem of handling faults.  It's
always possible for an access to the mapped region to fault because of an
EIO error in the filesystem backing the page.  If that happens inside a
stdio function or inside the getc macro, it should be handled and just
return a normal stdio error, rather than letting the signal through to the
program.  Do you have a plan to address that issue?


I had previously planned to move Hurd users over to libio before 2.3, and
completely excise the old stdio implementation from the source in 2.3.  We
may still be able to do that soon enough not to support the old (current)
Hurd ABI with GNU stdio in 2.3 at all, but I can't be sure yet.

I have a Hurd-specific aio implementation that might be ready for 2.3, and
also possibly a posix_spawn implementation.  Aside from that, I don't
anticipate anything else for Hurd in 2.3 other than bug fixes and possibly
incorporating more ports.



Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]