libthr and 1:1 threading.

[Igor Sysoev]

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/