Subject: Re: pthreads and MOL
From: Samuel Rydh (samuel@ibrium.se)
Date: Tue Aug 29 2000 - 16:37:49 MDT
On Tue, Aug 29, 2000 at 02:33:47PM +0200, Benjamin Herrenschmidt wrote:
> Hi Samuel !
>
> Have you seen the recent discussion on the kernel mailing list about
> pthreads ? As far as I understand things, pthreads in Linux, espcially
> when dealing with signals, have semantics that are quite different than
> what the linux kernel provides, meaning that there's a pile of emulation
> layer in the pthread lib itself, which may not be optimal. AFAIK, MOL
> uses pthreads...
No, I haven't (but I'll take a look). Also, pthreads are
still quite buggy.
> So I was wondering if there was any interest in switching to another more
> "native" threading mecanism (linuxthreads ?) and/or directly use kernel
> primitives to control the various MOL threads.
That is a thought. Otherwise, I've been working on eliminating
the number of threads. I implemented a generic asynchronous
I/O interface when I did the ethernet modifications. The idea was
to use a single thread which watches the file descriptor. When I/O is
possible, the main thread is signaled. This way, no locks are
needed and the latency ought to be minimal. If the watch thread
is given a high priority (real-time scheduling?), the delay
from that it becomes runnable till it is actually running
should be minimal.
Btw. I've test-implemented a fast save/restore feature.
State information and the RAM are dumped to a file. This
way, the MOL session can be restarted in less than three
seconds (by using file-mapped RAM to avoid having
to load all of it immediately). It is also possible
to save the session very fastly if the memory is
file-mapped (also typcially less than three seconds).
I'm not sure about the performance impact if file-mapped
RAM is used instead of zero-paged. It is clearly
unefficient in the case of a real reboot. Possibly
one could start with zero-mapped pages and then gradually
change dirty pages to file-mapped ones when MacOS is
idle/dozing.
Of course, one big problem with the save/restore feature
is the considerable risk for disk corruption if mounted
volumes are modified "externally". I hope there is a
mount counter for HFS(+) volumes which can be examined
(I haven't yet checked if this is indeed the case). If
no such counter exists, there should at least be a
volume-clean bit which can be used to guard against
the most common misuses.
Cheers,
/Samuel
----------------------------------------------------------
E-mail <samuel@ibrium.se> WWW: <http://www.ibrium.se>
Phone/fax: (home) +46 8 4418431, (work) +46 8 7908470
----------------------------------------------------------
This archive was generated by hypermail 2a24 : Tue Aug 29 2000 - 16:43:13 MDT