Hi all,
Just a note. Apache2 in per-child mode now works
with freebsd, while it deadlocked in the old libc_r
on STABLE and CURRENT.
Thank you very much !
Martin
___
[EMAIL PROTECTED] mailing list
On Mon, Mar 31, 2003 at 10:54:45PM -0500, Jeff Roberson wrote:
I have commited libthr. To try this out you'll need to do the following
I know very very little about threads, but I'm interested as to what the
purpose is of this library. Is there a document available somewhere that
describes the
Stijn Hoop wrote:
On Mon, Mar 31, 2003 at 10:54:45PM -0500, Jeff Roberson wrote:
I have commited libthr. To try this out you'll need to do the following
I know very very little about threads, but I'm interested as to what the
purpose is of this library. Is there a document available
On Tue, 01 Apr 2003 23:28:01 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
The primary performance reasoning behind a 1:1 kernel threading
implementation, relative to the user space single kernel entry
scheduler in the libc_r implementation is SMP scalability for
threaded applications.
I
Alexander Leidinger wrote:
On Tue, 01 Apr 2003 23:28:01 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
The primary performance reasoning behind a 1:1 kernel threading
implementation, relative to the user space single kernel entry
scheduler in the libc_r implementation is SMP scalability for
On (2003/04/02 06:05), Terry Lambert wrote:
I think Jeff (or someone else?) said, that some web browsers gain
something too (serialization issues with libc_r)? I had the impression
that this also applies to UP systems.
Do I misremember this? If not, does it not apply to UP systems as
On Wed, 2 Apr 2003, Sheldon Hearn wrote:
On (2003/04/02 06:05), Terry Lambert wrote:
I think Jeff (or someone else?) said, that some web browsers gain
something too (serialization issues with libc_r)? I had the impression
that this also applies to UP systems.
Do I misremember
Sheldon Hearn wrote:
On (2003/04/02 06:05), Terry Lambert wrote:
Do I misremember this? If not, does it not apply to UP systems as well?
FWIW: the libc_r reentrancy isn't fixed by a 1:1 model for
anything but calls for which there are no non-blocking
alternative kernel APIs. [...long
Robert Watson wrote:
You should notice marked interactivity and UI latency improvements with
threaded GUI apps over libc_r because GUI threads will generally no longer
be blocked when disk I/O and blocking I/O occurs. For example,
applications like Open Office, Netscape, et al, really get a
On (2003/04/02 07:38), Terry Lambert wrote:
Is the disk I/O really that big of an issue? All writes will
be on underlying non-blocking descriptors; I guess you are
saying that the interleaved I/O is more important, further
down the system call interface than the top, and this becomes
an
On Wed, Apr 02, 2003 at 07:38:14AM -0800, Terry Lambert wrote:
Has anyone tried compiling X11 to use libthr?
Someone reported success with KDE, so it should serve as a sign of working X11.
Jiawei
--
Without the userland, the kernel is useless.
--inspired by
On Wed, 2 Apr 2003, Terry Lambert wrote:
Is the disk I/O really that big of an issue? All writes will be on
underlying non-blocking descriptors; I guess you are saying that the
interleaved I/O is more important, further down the system call
interface than the top, and this becomes an issue?
You should notice marked interactivity and UI latency improvements with
threaded GUI apps over libc_r because GUI threads will generally no longer
be blocked when disk I/O and blocking I/O occurs. For example,
applications like Open Office, Netscape, et al, really get a lot better
with
On Wed, 2 Apr 2003, Terry Lambert wrote:
Robert Watson wrote:
You should notice marked interactivity and UI latency improvements with
threaded GUI apps over libc_r because GUI threads will generally no longer
be blocked when disk I/O and blocking I/O occurs. For example,
applications
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1 threading. ]
On Wed, 2 Apr 2003, Terry Lambert wrote:
Also, any ETA on the per process signal mask handing bug in
libthr? Might not be safe to convert everything up front, in
a rush of eager
On Wed, 2 Apr 2003, Juli Mallett wrote:
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1 threading. ]
On Wed, 2 Apr 2003, Terry Lambert wrote:
Also, any ETA on the per process signal mask handing bug in
libthr? Might not be safe to convert
Terry Lambert wrote:
Jun Su wrote:
[ ... 1:1 kernel threads implementation ... ]
A benchmark would be interested.
This request doesn't make sense.
The primary performance reasoning behind a 1:1 kernel threading
implementation, relative to the user space single kernel entry
On Wed, 2 Apr 2003, Jeff Roberson wrote:
On Wed, 2 Apr 2003, Juli Mallett wrote:
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1 threading. ]
On Wed, 2 Apr 2003, Terry Lambert wrote:
Also, any ETA on the per process signal mask handing
Sheldon Hearn wrote:
On (2003/04/02 07:38), Terry Lambert wrote:
Is the disk I/O really that big of an issue? All writes will
be on underlying non-blocking descriptors; I guess you are
saying that the interleaved I/O is more important, further
down the system call interface than the top,
On Wed, 2 Apr 2003, Juli Mallett wrote:
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1 threading. ]
On Wed, 2 Apr 2003, Terry Lambert wrote:
Also, any ETA on the per process signal mask handing bug in
libthr? Might not be safe
On Wed, 2 Apr 2003, Jeff Roberson wrote:
On Wed, 2 Apr 2003, Juli Mallett wrote:
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1 threading. ]
On Wed, 2 Apr 2003, Terry Lambert wrote:
Also, any ETA on the per process signal mask handing
leafy wrote:
On Wed, Apr 02, 2003 at 07:38:14AM -0800, Terry Lambert wrote:
Has anyone tried compiling X11 to use libthr?
Someone reported success with KDE, so it should serve as a sign of working X11.
Not X11 clients.
The X11 server.
-- Terry
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1 threading. ]
leafy wrote:
On Wed, Apr 02, 2003 at 07:38:14AM -0800, Terry Lambert wrote:
Has anyone tried compiling X11 to use libthr?
Someone reported success with KDE, so it should serve
On 02-Apr-2003 Terry Lambert wrote:
leafy wrote:
On Wed, Apr 02, 2003 at 07:38:14AM -0800, Terry Lambert wrote:
Has anyone tried compiling X11 to use libthr?
Someone reported success with KDE, so it should serve as a sign of working X11.
Not X11 clients.
The X11 server.
Gee, I
Terry Lambert wrote:
leafy wrote:
On Wed, Apr 02, 2003 at 07:38:14AM -0800, Terry Lambert wrote:
Has anyone tried compiling X11 to use libthr?
Someone reported success with KDE, so it should serve as a sign of working X11.
Not X11 clients.
The X11 server.
-- Terry
On Wed, 2 Apr 2003, Julian Elischer wrote:
On Wed, 2 Apr 2003, Juli Mallett wrote:
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1 threading. ]
On Wed, 2 Apr 2003, Terry Lambert wrote:
Also, any ETA on the per process signal mask
On Wed, 2 Apr 2003, Jeff Roberson wrote:
On Wed, 2 Apr 2003, Julian Elischer wrote:
On Wed, 2 Apr 2003, Juli Mallett wrote:
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1 threading. ]
On Wed, 2 Apr 2003, Terry Lambert wrote
Robert Watson wrote:
On Wed, 2 Apr 2003, Terry Lambert wrote:
Is the disk I/O really that big of an issue? All writes will be on
underlying non-blocking descriptors; I guess you are saying that the
interleaved I/O is more important, further down the system call
interface than the top,
On Wed, 2 Apr 2003, Daniel Eischen wrote:
On Wed, 2 Apr 2003, Jeff Roberson wrote:
On Wed, 2 Apr 2003, Julian Elischer wrote:
On Wed, 2 Apr 2003, Juli Mallett wrote:
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
[ Subjecte: Re: libthr and 1:1
On 02-Apr-2003 Terry Lambert wrote:
The only way I see for disk I/O to be involved in Mozilla is in
local cache? You can turn that off.
Umm, the idea here is to actually make threaded programs
_useful_. Not to require that you trim their functionality
down before we handle them in a sane
John Baldwin wrote:
On 02-Apr-2003 Terry Lambert wrote:
The only way I see for disk I/O to be involved in Mozilla is in
local cache? You can turn that off.
Umm, the idea here is to actually make threaded programs
_useful_. Not to require that you trim their functionality
down before
[ CC list trimmed somewhat ]
On Wed, 2 Apr 2003, Jeff Roberson wrote:
On Wed, 2 Apr 2003, Daniel Eischen wrote:
On Wed, 2 Apr 2003, Jeff Roberson wrote:
Then set the mask to be the same on all threads in the process. The mask
is set in swapcontext though so it seems reasonable to me
On Wed, 2 Apr 2003, Daniel Eischen wrote:
[ CC list trimmed somewhat ]
On Wed, 2 Apr 2003, Jeff Roberson wrote:
On Wed, 2 Apr 2003, Daniel Eischen wrote:
On Wed, 2 Apr 2003, Jeff Roberson wrote:
Then set the mask to be the same on all threads in the process. The mask
is set
Jeff Roberson wrote:
On Wed, 2 Apr 2003, Terry Lambert wrote:
Is the disk I/O really that big of an issue? All writes will
be on underlying non-blocking descriptors; I guess you are
saying that the interleaved I/O is more important, further
down the system call interface than the top,
Juli Mallett wrote:
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ]
On Wed, 2 Apr 2003, Terry Lambert wrote:
Also, any ETA on the per process signal mask handing bug in
libthr? Might not be safe to convert everything up front, in
a rush of eager enthusiasm...
Which bug
Terry Lambert wrote:
KSE mailing list, starting Monday or so:
] We still haven't heard from jeff with regard to the process
] signal mask removal.
We can add new mailing lists really easily now - it takes about 20-30 seconds.
Would it be worth adding a freebsd-threads and/or freebsd-kse type
On Wed, 2 Apr 2003, Peter Wemm wrote:
:Terry Lambert wrote:
:
: KSE mailing list, starting Monday or so:
: ] We still haven't heard from jeff with regard to the process
: ] signal mask removal.
:
:We can add new mailing lists really easily now - it takes about 20-30 seconds.
:Would it be worth
Jeff Roberson wrote:
Perhaps I should start quoting posix. I wonder what my legal rights
are given the copyright. hm..
Educational use.
FWIW, my reading of POSIX.1 says Per process mask, per threads
masks.
The real question is What happens when I kill -9/-15 a libthr
process with a lot of
Peter Wemm wrote:
No. It gives the ability for a thread to block on a syscall without
stalling the entire system. Just try using mysqld on a system using libc_r
and heavy disk IO. You can't select() on a read() from disk. Thats the
ultimate reason to do it. The SMP parallelism is a bonus.
On Wed, 2 Apr 2003, Peter Wemm wrote:
Terry Lambert wrote:
KSE mailing list, starting Monday or so:
] We still haven't heard from jeff with regard to the process
] signal mask removal.
We can add new mailing lists really easily now - it takes about 20-30 seconds.
Would it be worth
On Wed, 2 Apr 2003, Terry Lambert wrote:
Peter Wemm wrote:
No. It gives the ability for a thread to block on a syscall without
stalling the entire system. Just try using mysqld on a system using libc_r
and heavy disk IO. You can't select() on a read() from disk. Thats the
ultimate
Terry Lambert wrote:
Peter Wemm wrote:
No. It gives the ability for a thread to block on a syscall without
stalling the entire system. Just try using mysqld on a system using libc_r
and heavy disk IO. You can't select() on a read() from disk. Thats the
ultimate reason to do it. The
On Wed, Apr 02, 2003 at 06:37:21PM -0500, Daniel Eischen wrote:
On Wed, 2 Apr 2003, Peter Wemm wrote:
Terry Lambert wrote:
KSE mailing list, starting Monday or so:
] We still haven't heard from jeff with regard to the process
] signal mask removal.
We can add new mailing
:Terry Lambert wrote:
: Peter Wemm wrote:
: No. It gives the ability for a thread to block on a syscall without
: stalling the entire system. Just try using mysqld on a system using libc_r
: and heavy disk IO. You can't select() on a read() from disk. Thats the
: ultimate reason to do it.
Matthew Dillon wrote:
A better solution would be to give AIO the capability to
operate synchronously if the operation would occur in a
non-blocking fashion (inclusive of blockages on page faults),
and asynchronously otherwise.
Without wanting to get too far off into the
Peter Wemm wrote:
Terry Lambert wrote:
KSE mailing list, starting Monday or so:
] We still haven't heard from jeff with regard to the process
] signal mask removal.
We can add new mailing lists really easily now - it takes about 20-30 seconds.
Would it be worth adding a
Jeff Roberson wrote:
On Wed, 2 Apr 2003, Terry Lambert wrote:
Peter Wemm wrote:
No. It gives the ability for a thread to block on a syscall without
stalling the entire system. Just try using mysqld on a system using libc_r
and heavy disk IO. You can't select() on a read() from disk.
That's a cute trick. The ultimate solution is to implement
a semi-synchronous message passing API to replace the myrid
system calls we have now. Roughly speaking, what the Amiga
did for messages, ports, and I/O, is far superior then what
is done in Linux and *BSD. You get
Peter Wemm wrote:
Terry Lambert wrote:
Peter Wemm wrote:
No. It gives the ability for a thread to block on a syscall without
stalling the entire system. Just try using mysqld on a system using libc_r
and heavy disk IO. You can't select() on a read() from disk. Thats the
ultimate
Matthew Dillon wrote:
Peter Wemm wrote:
:Terry Lambert wrote:
: No. It gives the ability for a thread to block on a syscall without
: stalling the entire system. Just try using mysqld on a system using libc_r
: and heavy disk IO. You can't select() on a read() from disk. Thats the
:
Terry Lambert wrote:
Stijn Hoop wrote:
On Mon, Mar 31, 2003 at 10:54:45PM -0500, Jeff Roberson wrote:
I have commited libthr. To try this out you'll need to do the following
I know very very little about threads, but I'm interested as to what the
purpose is of this library. Is
:How does this break the read() API? The read() API, when called
:on a NBIO fd is *supposed* to return EAGAIN, if the request cannot
:be immediately satisfied, but could be satisfied later. Right now,
:it blocks. This looks like breakage of disk I/O introducing a
:stall, when socket I/O
A thought on 'fixing AIO..'
On Wed, 2 Apr 2003, Matthew Dillon wrote:
A better solution would be to implement a new system call, similar to
pread(), which simply checks the buffer cache and returns a short read
or an error if the data is not present. If the call fails you
Julian Elischer wrote:
Yes I think so..
I think 'threads is a better name thatn 'kse' though kse
is good in that it's real quick to type :-)
OK, done. It seems to me we've needed one for a while now.
Subscribe by either:
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
or
echo
can we have a subject ID?
the KSE list prefixes with [KSE] and I've grown used to not ignoring
those :-)
On Wed, 2 Apr 2003, Peter Wemm wrote:
Julian Elischer wrote:
Yes I think so..
I think 'threads is a better name thatn 'kse' though kse
is good in that it's real quick to type :-)
I have commited libthr. To try this out you'll need to do the following
1. cvsup
2. rebuild world and kernel
3. install world and kernel
4. build libthr from src/lib/libthr
5. Either replace /usr/lib/libc_r.so.5 with /usr/lib/libthr.so.1 or
relink your applications against
Matthew Dillon wrote:
:How does this break the read() API? The read() API, when called
:on a NBIO fd is *supposed* to return EAGAIN, if the request cannot
:be immediately satisfied, but could be satisfied later. Right now,
:it blocks. This looks like breakage of disk I/O introducing a
On Tue, 1 Apr 2003, Scott Long wrote:
Jeff Roberson wrote:
I have commited libthr. To try this out you'll need to do the following
Excellent job Jeff and Jon, thanks a lot!
Is anyone working on getting full Apache2 support for this? Also,
linking the Java 1.3 and 1.4 ports to this
Jeff Roberson wrote:
I have commited libthr. To try this out you'll need to do the following
1. cvsup
2. rebuild world and kernel
3. install world and kernel
4. build libthr from src/lib/libthr
5. Either replace /usr/lib/libc_r.so.5 with /usr/lib/libthr.so.1 or
relink your
--- Jacques A. Vidrine [EMAIL PROTECTED]
On Mon, Mar 31, 2003 at 10:54:45PM -0500,
Jeff
Roberson wrote:
5. Either replace /usr/lib/libc_r.so.5 with
/usr/lib/libthr.so.1 or
relink your applications against libthr.so.1
Happily strlen(libc_r.so.5) == strlen(libthr.so.1),
so you can
Jun Su wrote:
[ ... 1:1 kernel threads implementation ... ]
A benchmark would be interested.
This request doesn't make sense.
The primary performance reasoning behind a 1:1 kernel threading
implementation, relative to the user space single kernel entry
scheduler in the libc_r implementation
I have commited libthr. To try this out you'll need to do the following
1. cvsup
2. rebuild world and kernel
3. install world and kernel
4. build libthr from src/lib/libthr
5. Either replace /usr/lib/libc_r.so.5 with /usr/lib/libthr.so.1 or
relink your applications against libthr.so.1
This
62 matches
Mail list logo
