Date: Thu, 3 Apr 2003 13:57:06 +0400 (MSD) From: Igor Sysoev <is@rambler-co.ru> To: freebsd-arch@freebsd.org Subject: Re: libthr and 1:1 threading. Message-ID: <Pine.BSF.4.21.0304031307220.32175-100000@is>
next in thread | raw e-mail | index | archive | help
Terry Lambert wrote: >> Well, they're both fixes. Another issue for applications that are >> threaded and may be bumping up against the system memory limits is whether >> or not the whole process stalls on a page fault or memory mapping fault, >> or whether it's just the thread. >This is what I meant by "deeper in the system calll layer". IMO, >if you are stalled on something like this on an async fd, then it >should queue the fault anyway, and return to user space for the >next request. This may just be a bug in the kernel processing of >demand faults on vnodes associated with async fd's (FWIW, System V >and Solaris both queue the fault for kernel processing, and then >return to user space). If a process caused a page fault or memory mapping fault at user level where do you suppose to return in user space after a fault was just queued ? To the same instruction that caused this fault ? With threads you can run another thread in such situation. BTW what do you mean by 'async fd' in Solaris ? O_ASYNC ? I do not see it in Solaris 8. O_NONBLOCK ? It does not matter for disk files. aioread() or aio_read() ? They are library calls that implemented via additional LWP for regular disk files. >> Certainly, you can argue that the application should be structured >> to make all I/O explicit and asynchronous, but for various reasons, >> that's not the case :-). >The mmap'ed file case is obviously not something that can be >handled without an explicit contract between user and kernel >for notification of the pagein temporary failure (I would use >a signal for that, probably, as a gross first approximation, >but per-process signal handling is currently not happy...). And what do you suppose to do in a signal handler ? Using some non-reenterant library functions ? Igor Sysoev http://sysoev.ru/en/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0304031307220.32175-100000>