t;td_priority < curthread->td_priority)
curthread->td_kse->ke_flags |= KEF_NEEDRESCHED;
}
--
Richard Seaman, Jr.email:[EMAIL PROTECTED]
5182 N. Maple Lane phone:262-367-5450
Nashotah WI 53058fax:262-367-5852
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
n I have the time, unless you beat me to it.
There are some gethostby_r, getnetby_r, ... etc routines in the
linuxthreads port (/usr/ports/devel/linuxthreads/files). These
came from the original linuxthreads package, and have no copyright
on them. I never researched the copyright status of them, b
Whoops. Meant to cc this to the list too.
--
Richard Seaman, Jr.email:[EMAIL PROTECTED]
5182 N. Maple Lane phone:262-367-5450
Nashotah WI 53058fax:262-367-5852
On Sat, Jul 28, 2001 at 12:19:01PM +0100, [EMAIL PROTECTED] wrote:
> I'm worried a
ld be improved with SCHED_OTHER,
except in very restricted situations?
--
Richard Seaman, Jr.email:[EMAIL PROTECTED]
5182 N. Maple Lane phone:262-367-5450
Nashotah WI 53058fax:262-367-5852
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, Apr 28, 2000 at 06:13:32PM -0400, Brian Fundakowski Feldman wrote:
> On Fri, 28 Apr 2000, Richard Seaman, Jr. wrote:
>
> > There may be additional issues with the scheduler, though they may not
> > be related to the issue you have. Check www.freebsd.org/~dick/sched.des
There may be additional issues with the scheduler, though they may not
be related to the issue you have. Check www.freebsd.org/~dick/sched.descr
I was under the impression that Peter Dufault had re-assumed this matter,
but not much has happened on most of the issues.
--
Richard Seaman, Jr
ary that multiplexes threads in a single
> process. This style of threads library should perform well for the type of
> application you are dealing with.
Perhaps. The proposed "new" threads model that I understand you are working
on should be *much* superior in this kind of application t
t get *any* of the
thread safe behaviour in libc, libgcc, or in ld-ef.so.
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax: 262-367-5852
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
and linuxthreads. A genuine
> libpthread is just a hop, skip, and a jump from there.
I'd say only do whats necessary, if thats the case. Someone really good
with sed, or some other text processor, might be able to semi-automate
the process, but I know I don't know how.
This will b
In theory the problem should exist
for libc_r, but I don't know of any reports.
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax: 262-367-5852
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
't complain. =)
I'm not volunteering. But, I promised you some thoughts on how to do it,
which I still owe you. I don't think its "hard", just tedious.
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 5
, because libc_r carefully unwinds any internal locks
created within libc. Linuxthreads does not have this capability,
and the sample program deadlocks (at least it does here).
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI
On Tue, Dec 28, 1999 at 08:30:08AM -0600, Richard Seaman, Jr. wrote:
> On Tue, Dec 28, 1999 at 10:44:19AM +0100, Steffen Merkel wrote:
>
> > Sorry, but I'm learning C for only some weeks now. Why does the main
> > thread complete if I insert a while(1); ? I thougt th
ght, of course. My brain was not fully in gear when I wrote that.
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax: 262-367-5852
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe free
FreeBSD user threads used to use
SIGVTALRM for its pre-emption signal. This didn't count time in
syscalls. So, if you had a syscall (eg I/O) intensive thread, it
would hog processor time. I think that has been changed.
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182
reads have fairly high context switch overhead, especially
when there are open fds that get polled on each context switch. Kernel
threads are actually faster in many circumstances. The discussion in
the -arch mailing list involves ideas which would make user threads much
more efficient.
--
Richar
ds
with PTHREAD_SCOPE_PROCESS threads), but only if you need the
added functionality.
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax: 262-367-5852
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
se select(). And, not only at each thread
context switch, but each time it has to consider whether to
do a switch at all (eg. at the end of a timeslice).
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax: 262
are a lot slower
than kernel thread context switches.
Also note that you can try kernel threads using ports/devel/linuxthreads.
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax: 262-367-5852
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote:
> Richard Seaman, Jr. wrote:
> > Actually, I don't think all that many apps use pthread_cancel().
> > Its kind of messy to use. Most can get along without it, which
> > is why there have only been a li
On Thu, Dec 09, 1999 at 12:57:45PM -0800, Jason Evans wrote:
> On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> > On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote:
> >
> > The problem with cancellation points, libc and linuxthreads has been
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> In this case, you'd want, for example, an _lseek(), _libc_lseek(),
> and _seek().
I meant "and lseek()", not _seek().
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lane
may make some people's skin crawl. Feedback is
> welcome. If there is no correct way to create aliases to function entry
> points, then we can do without them, but it will mean that the *jmp()
> functions cannot be used in conjunction with thread cleanup handlers when
> using LinuxThr
23 matches
Mail list logo
