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
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
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
>
> 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 li
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 :-
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 "su
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
: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 doesn't
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 :-)
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
> >
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 ther
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
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
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 th
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()
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 w
: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 t
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 ad
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
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
> > ul
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 b
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 bon
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 o
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
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 typ
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...
>
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
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 ma
[ 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 reason
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
> dow
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 wa
[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
> > > > > > l
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
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
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:
&
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 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.
* 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?
> >
> > Some
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, 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:
> &g
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
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
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:
> > >
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 e
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
* 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
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,
> > applica
> > 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
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 iss
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 b
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
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
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.
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.
> > >
> > >
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 s
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 scalabi
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
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 s
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
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 implementati
--- "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)
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
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
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 might be interesting.
Scott
__
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 might be interesting.
Scott
__
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 also
edit your binaries' SONEEDED fields in place :-)
64 matches
Mail list logo
