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] |
> 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] |