libthr and 1:1 threading.
is at rambler-co.ru
Thu Apr 3 01:57:17 PST 2003
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 ?
More information about the freebsd-arch