tid leads to a NULL thread_info [via find_thread_ptid(~)],
we will get hosed on an assert.
Any thoughts?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/Problem-with-running-simple-pthreads-program-under-gdb-7-2-Invalid-selected-thread-tp4426179p4803024.html
Sent from the fre
On Thursday, May 26, 2011 8:03:19 pm Raphael Kubo da Costa wrote:
> Andriy Gapon writes:
>
> > on 26/05/2011 16:33 John Baldwin said the following:
> >> On Thursday, May 26, 2011 3:37:13 am Andriy Gapon wrote:
> >>> on 26/05/2011 03:35 Raphael Kubo da Costa said the following:
> If I compile
Andriy Gapon writes:
> on 26/05/2011 16:33 John Baldwin said the following:
>> On Thursday, May 26, 2011 3:37:13 am Andriy Gapon wrote:
>>> on 26/05/2011 03:35 Raphael Kubo da Costa said the following:
If I compile the port myself, I can't run any binary (PR ports/152896,
which has been
on 26/05/2011 16:33 John Baldwin said the following:
> On Thursday, May 26, 2011 3:37:13 am Andriy Gapon wrote:
>> on 26/05/2011 03:35 Raphael Kubo da Costa said the following:
>>> If I compile the port myself, I can't run any binary (PR ports/152896,
>>> which has been unanswered despite my effort
On Thursday, May 26, 2011 3:37:13 am Andriy Gapon wrote:
> on 26/05/2011 03:35 Raphael Kubo da Costa said the following:
> > If I compile the port myself, I can't run any binary (PR ports/152896,
> > which has been unanswered despite my efforts):
> >
> > Reading symbols from /usr/local/bin/gdb72
On Wednesday, May 25, 2011 8:35:28 pm Raphael Kubo da Costa wrote:
> Dmitry Krivenok writes:
>
> > As you can see program exited normally w/o any errors.
> > Then I run the same program under gdb-7.2
> >
> > $ /usr/local/bin/gdb72 --args t
> > GNU gdb (GDB) 7.2 [GDB v7.2 for FreeBSD]
> > Copyrigh
on 26/05/2011 03:35 Raphael Kubo da Costa said the following:
> If I compile the port myself, I can't run any binary (PR ports/152896,
> which has been unanswered despite my efforts):
>
> Reading symbols from /usr/local/bin/gdb72...I'm sorry, Dave, I can't
> do that. Symbol format `elf64-x86-
Dmitry Krivenok writes:
> As you can see program exited normally w/o any errors.
> Then I run the same program under gdb-7.2
>
> $ /usr/local/bin/gdb72 --args t
> GNU gdb (GDB) 7.2 [GDB v7.2 for FreeBSD]
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or la
Hello,
I wrote very simple Pthreads program to demonstrate the problem with
gdb-7.2 installed from
ports on my FreeBSD-8.2 (amd64).
///
#include
#include
#include
void* run(void* arg)
{
return 0;
}
int main(int argc
On 06/03/2011 18:35, Ryan Stone wrote:
On Sun, Mar 6, 2011 at 10:34 AM, Ryan Stone wrote:
I would try playing with MALLOC_OPTIONS. I seriously doubt that there
is an actual leak in jemalloc, but from my own experiences with it I
suspect that there are certain multithreaded malloc/free sequence
rote:
> >> Hi all,
> >>
> >> I have a moderately threaded userland program (all C) I am working on
> >> (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using
> >> standard malloc/free) badly.
> > as opposed to what? OpenBSD? Linux? Wi
On Mar 6, 2011, at 11:35 AM, Ryan Stone wrote:
> On Sun, Mar 6, 2011 at 10:34 AM, Ryan Stone wrote:
>> I would try playing with MALLOC_OPTIONS. I seriously doubt that there
>> is an actual leak in jemalloc, but from my own experiences with it I
>> suspect that there are certain multithreaded ma
On Sun, Mar 6, 2011 at 10:34 AM, Ryan Stone wrote:
> I would try playing with MALLOC_OPTIONS. I seriously doubt that there
> is an actual leak in jemalloc, but from my own experiences with it I
> suspect that there are certain multithreaded malloc/free sequences
> that interact badly with with th
I would try playing with MALLOC_OPTIONS. I seriously doubt that there
is an actual leak in jemalloc, but from my own experiences with it I
suspect that there are certain multithreaded malloc/free sequences
that interact badly with with the per-thread caching that jemalloc
performs. The first thin
gt;> >> I have a moderately threaded userland program (all C) I am working on
>> (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using
>> standard malloc/free) badly.
>> > as opposed to what? OpenBSD? Linux? Windows? why do you think your
>> proble
On Sun, Mar 6, 2011 at 6:53 AM, Eric Anderson wrote:
> On Mar 5, 2011, at 10:44 AM, Deomid Ryabkov wrote:
>
> > On 03/05/2011 04:02 AM, Eric Anderson wrote:
> >> Hi all,
> >>
> >> I have a moderately threaded userland program (all C) I am working on
>
On Mar 5, 2011, at 10:44 AM, Deomid Ryabkov wrote:
> On 03/05/2011 04:02 AM, Eric Anderson wrote:
>> Hi all,
>>
>> I have a moderately threaded userland program (all C) I am working on (using
>> pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard
On Mar 5, 2011, at 6:23 AM, Eygene Ryabinkin wrote:
> Fri, Mar 04, 2011 at 10:02:45PM -0600, Eric Anderson wrote:
>> I have a moderately threaded userland program (all C) I am working
>> on (using pthreads, freebsd 8.1 64bit). It seems to leak memory
>> (using standard mall
On 03/05/2011 04:02 AM, Eric Anderson wrote:
Hi all,
I have a moderately threaded userland program (all C) I am working on (using
pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard
malloc/free) badly.
as opposed to what? OpenBSD? Linux? Windows? why do you think your
Fri, Mar 04, 2011 at 10:02:45PM -0600, Eric Anderson wrote:
> I have a moderately threaded userland program (all C) I am working
> on (using pthreads, freebsd 8.1 64bit). It seems to leak memory
> (using standard malloc/free) badly. I am using pcap to capture
> packets and process th
Hi all,
I have a moderately threaded userland program (all C) I am working on (using
pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard
malloc/free) badly. I am using pcap to capture packets and process them. I
have a handful of libs statically linked in (pcap is one, the
On Wed, 28 Mar 2007, Peter Holmes wrote:
How do signals work with pthreads in FreeBSD. How are process signals
delivered?
The best explanation of signals and threads in general
is in the POSIX spec, or Butenhof's book.
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap
How do signals work with pthreads in FreeBSD. How are process signals delivered?
- Peter
-
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
___
Pieter de Goeje wrote:
On Tuesday 28 November 2006 23:41, Garrett Cooper wrote:
So that means no, after a function's definition is reached the
thread/resources stay in a semi-'alive' (maybe 'zombified') state?, or
does the kernel cleanup / reclaim all of the resources tied up with the
thread?
On Tuesday 28 November 2006 23:41, Garrett Cooper wrote:
> So that means no, after a function's definition is reached the
> thread/resources stay in a semi-'alive' (maybe 'zombified') state?, or
> does the kernel cleanup / reclaim all of the resources tied up with the
> thread?
> -Garrett
If you de
Pieter de Goeje wrote:
On Tuesday 28 November 2006 22:33, Garrett Cooper wrote:
Hello once again,
Just wondering about pthreads now. I know that the lifetime (scope)
of a regular procedural function in C is simple.. it's from the top of
the function body to the bottom of the fun
On Tuesday 28 November 2006 22:33, Garrett Cooper wrote:
> Hello once again,
> Just wondering about pthreads now. I know that the lifetime (scope)
> of a regular procedural function in C is simple.. it's from the top of
> the function body to the bottom of the function
Hello once again,
Just wondering about pthreads now. I know that the lifetime (scope)
of a regular procedural function in C is simple.. it's from the top of
the function body to the bottom of the function body (assuming no
infinite loops are injected). Example:
(void*) function
Hi
The startup of this program causes memory leak, doesn't it? What's the
reason?
Tested on FreeBSD-6.1 and 5.4 with the same effect.
On Linux work fine.
#include
#include
#include
void* mythread(void* arg)
{
return NULL;
}
void threaded()
{
#define si
Hi
The startup of this program causes memory leak, doesn't it? What's the
reason?
Tested on FreeBSD-6.1 and 5.4 with the same effect.
On Linux work fine.
#include
#include
#include
void* mythread(void* arg)
{
return NULL;
}
void threaded()
{
#define size
Hi Phil,
I think the easiest solution for your problem is something like this:
#include
#include
volatile unsigned long len = 0;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
static void cleanup_handler(void *arg) {
(void)pt
Philip S. Schulz wrote:
P.S:: Attached is the full example.
Oh, well, apparently I'm too dumb to use my mail reader correctly... it
is at http://aliue.homeunix.net:8000/threads.c
Phil.
___
freebsd-hackers@freebsd.org mailing list
http://lists.fre
Hi!
From the what's-wrong-with-my-code department...
I'm having trouble with two threads accessing a queue. One thread
writes to it while the other one reads from the queue. I'd like the
consumer to run until the main thread (which is the producer) decides
that the consumer thread should ex
Jeremie Le Hen wrote:
> Hi Christophe,
>
> a quick glance at the archives whould have helped you.
I also experienced the problem and read the thread. I don't believe
anybody found and shared a way to solve it. The conclusion of the thread
was that the problem is more in the application then in Fr
Hi Michal,
> I also experienced the problem and read the thread. I don't believe
> anybody found and shared a way to solve it. The conclusion of the thread
> was that the problem is more in the application then in FreeBSD - the
> application does things not well defined in POSIX threading environm
Thanks Jeremie,
I will asked nagios developpers how to use libpthread, if there is a
configure option when compiling...
Bye.
> Christophe,
>
>> Yes but if i understand, there is a bug in libc_r on FreeBSD ?
>
> libc_r indeed has some kind of bug, I don't know.
>
> Anyhow, you are using RELENG_5
Christophe,
> Yes but if i understand, there is a bug in libc_r on FreeBSD ?
libc_r indeed has some kind of bug, I don't know.
Anyhow, you are using RELENG_5, so you should be using native threads
with either libpthread (libkse, M:N) or libthr (1:1).
I don't know what Nagios does just after for
Hi,
Yes but if i understand, there is a bug in libc_r on FreeBSD ?
> Hi Christophe,
>
> a quick glance at the archives whould have helped you.
>
>> i know that we add already discuss about this problem, but is there any
>> solution for this problem ?
>>
>> ---
>> What's section on nagios website
Hi Christophe,
a quick glance at the archives whould have helped you.
> i know that we add already discuss about this problem, but is there any
> solution for this problem ?
>
> ---
> What's section on nagios website
> "FreeBSD and threads. On FreeBSD there's a native user-level
> implementation
Hi all,
i know that we add already discuss about this problem, but is there any
solution for this problem ?
---
What's section on nagios website
"FreeBSD and threads. On FreeBSD there's a native user-level
implementation of threads called 'pthread' and there's also an optional
ports collection '
[ I'm not snipping anything since I'm Cc'ing to [EMAIL PROTECTED] ]
On Thu, Jun 30, 2005 at 06:50:17PM +0200, Jeremie Le Hen wrote:
> Hello,
>
> maybe this question should be asked on -threads@, I'm not sure. If it
> is, please tell me and I will redirect my mail.
>
> I'm working on upgrading t
On Thursday 10 February 2005 15:46, Coleman Kane wrote:
> Could you post the code too, perchance?
>
> On Thu, 10 Feb 2005 10:55:04 +0200, Andriy Tkachuk <[EMAIL PROTECTED]> wrote:
> > Hi folks.
> >
> > I noticed the strange stick of pthreads
Could you post the code too, perchance?
On Thu, 10 Feb 2005 10:55:04 +0200, Andriy Tkachuk <[EMAIL PROTECTED]> wrote:
> Hi folks.
>
> I noticed the strange stick of pthreads (amount ~ 500)
> when allocating dynamic memory by malloc or new
> in my system:
>
> > un
Hi folks.
I noticed the strange stick of pthreads (amount ~ 500)
when allocating dynamic memory by malloc or new
in my system:
> uname -a
FreeBSD ant.emict.com 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb 9 17:30:11 EET
2005 [EMAIL PROTECTED]:/lin/fbsd_obj/usr/src/sys/ANT i386
I
Mark Tinguely wrote:
> Intel x86 hardware allows windows of 4GB of virtual memory even if
> you have the PSE-36 and the PAE extensions with more the 4GB of
> physical memory. Sound a little like Intel's 64KB windows, but
> if I remember correctly, the 4GB does not have to be contiguous.
>
> It wou
Andrew Kinney wrote:
> Really? I was under the impression that FreeBSD was capable of
> addressing 8TB of RAM if the hardware supports it. Don't
> remember which FreeBSD list archive I read that in, but it's not a
> topic that seems to come up often since most hardware is limited
> to 4GB of addr
Intel x86 hardware allows windows of 4GB of virtual memory even if
you have the PSE-36 and the PAE extensions with more the 4GB of
physical memory. Sound a little like Intel's 64KB windows, but
if I remember correctly, the 4GB does not have to be contiguous.
It would require a true MMU such as th
On Fri, 14 Mar 2003, Andrew Kinney wrote:
> On 14 Mar 2003, at 16:08, Julian Elischer wrote:
>
> >
> > That patch is in the RELENG_4 tree and will be included in 4.8
> >
>
> Great! Thanks for the info.
>
> >
> > yes it was.. but not in RELENG_4_7 because that is for security
> > patches.
On 14 Mar 2003, at 16:08, Julian Elischer wrote:
>
> That patch is in the RELENG_4 tree and will be included in 4.8
>
Great! Thanks for the info.
>
> yes it was.. but not in RELENG_4_7 because that is for security
> patches.
>
I'm showing my newbieness here. :-) Apologies. I knew that,
it was.. but not in RELENG_4_7 because that is for security patches.
>
> We're now tracking RELENG_4_7 (FreeBSD 4.7-RELEASE +
> security fixes). I haven't tried changing KVA_PAGES since version
> 4.5 and I'm a little gun-shy on changing that particular tunable
>
FreeBSD 4.7-RELEASE +
security fixes). I haven't tried changing KVA_PAGES since version
4.5 and I'm a little gun-shy on changing that particular tunable
since it has so many potential application gotchas, like with
pthreads.
The RELENG_4_7 CVS tree (updated yesterday) doesn't
On Tue, Oct 22, 2002 at 08:24:05AM +0300, Peter Pentchev wrote:
> On Mon, Oct 21, 2002 at 10:31:48PM +0200, Linus Kendall wrote:
> [snip]
> >
> > That was very thorough, thanks! Now I at least have a notion of what
> > is going on. Since this is slightly urgent I guess a hack into the
> > libcurl
On 14:34+0300, Nov 7, 2002, Mathieu Arnold wrote:
> Hi
>
> I'm having a bit of difficulties with pthreads, lets explain :
>
> $ cat test.c
> #include "pthread.h"
Shouldn't it be ?
> void * test (void* t) {
> while (1) {
> pr
Hi
I'm having a bit of difficulties with pthreads, lets explain :
$ cat test.c
#include "pthread.h"
void * test (void* t) {
while (1) {
printf("pouet");
sleep(1);
}
}
main () {
pthread_t th;
if (pthre
Bruce M Simpson wrote:
> On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote:
> > It is more correct to say that libcurl makes an assumption about
> > signal delivery which is not guaranteed by POSIX, and therefore
> > libcurl will not work with *any* POSIX compliant threads
> > implement
On Tue, 22 Oct 2002, Peter Pentchev wrote:
> On Tue, Oct 22, 2002 at 12:31:32PM +0100, Bruce M Simpson wrote:
> > On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote:
> > > It is more correct to say that libcurl makes an assumption about
> > > signal delivery which is not guaranteed by P
On Tue, Oct 22, 2002 at 12:31:32PM +0100, Bruce M Simpson wrote:
> On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote:
> > It is more correct to say that libcurl makes an assumption about
> > signal delivery which is not guaranteed by POSIX, and therefore
> > libcurl will not work with *
On Mon, Oct 21, 2002 at 10:31:48PM +0200, Linus Kendall wrote:
[snip]
>
> That was very thorough, thanks! Now I at least have a notion of what
> is going on. Since this is slightly urgent I guess a hack into the
> libcurl source code to try to remove the sigalarms would do the trick
> (in my case
> > > >
> > > > I'm trying to port a heavily threaded application from Linux (Debian
> > > > 3.0, 2.4.19) to
> > > > FreeBSD (4.6-RELEASE). The program compiles successfully using gcc with
> > > > -pthreads. But, when I try to
Linus Kendall wrote:
> That was very thorough, thanks! Now I at least have a notion of what
> is going on. Since this is slightly urgent I guess a hack into the
> libcurl source code to try to remove the sigalarms would do the trick
> (in my case). In the general case it seems like there's a rather
gt; > > > > > >
> > > > > > > I'm trying to port a heavily threaded application from Linux (Debian
> > > > > > > 3.0, 2.4.19) to
> > > > > > > FreeBSD (4.6-RELEASE). The program compiles successfully using gcc with
&g
On Mon, 21 Oct 2002, Peter Pentchev wrote:
> Okay, I can see what the problem is; however, I have absolutely no idea
> how it is to be solved :(
>
> The DNS resolution routines of libcurl use alarm() as a timeout
> mechanism for the system DNS resolving functions. To enforce the
> timeout even wh
--- Kip Macy <[EMAIL PROTECTED]> wrote:
> [...]
> As an aside: this only belongs on -questions. However, considering I got
> _zero_ response after posting to one then the other when one of my boxes
> failed to boot after cvsupping -STABLE and doing a make world I can
> understand the crosspostin
You need to remove the -ansi flag to the compilation to remove the warnings, and
add a -pthread to the link stage so that libc_r will be used instead of libc.
As an aside: this only belongs on -questions. However, considering I got _zero_
response after posting to one then the other when one of
-4-clients/work/xc/programs.
- Original Message -
From: "Matt" <[EMAIL PROTECTED]>
Date: Sunday, August 25, 2002 12:58 pm
Subject: Re: problems with pthreads
> You need to edit the makefile to take out the CFLAG of -ansi and add
> in -pthread so it will link
Solutions.
-
- Original Message -
From: "GERARDO ENRIQUE PAREDES MANCIA" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, August 25, 2002 4:36 AM
Subject: problems with pthreads
> when trying
when trying to portupgrade XFree86-clients from 4.2.??? to the newest version i
get this:
LD_LIBRARY_PATH=../../exports/lib cc -O -pipe -march=pentiumpro -ansi -pedantic
-Dasm=__asm -Wall -Wpointer-arith -I../.. -I../../exports/include
-DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROT
I've been studying a few things in pthreads to figure out a bug that's
had me banging my head against a wall. I'd be interested in knowing
what peoples' thoughts are.
The basic scenario is that a fd loses its schedulability after the
process calls daemon(). To review:
* Zach Brown <[EMAIL PROTECTED]> [010814 17:42] wrote:
> [pulls out his dead horse..]
>
> > > one thread would wake up. The mistake in your sample seems to be that
> > > you're having all threads block on the same fd. Why?
> >
> > Probably he has a bunch of daemons waiting around for work to
>
[pulls out his dead horse..]
> > one thread would wake up. The mistake in your sample seems to be that
> > you're having all threads block on the same fd. Why?
>
> Probably he has a bunch of daemons waiting around for work to
> do (e.g. HTTP daemons all listening for connections to accept
> on
"Daniel M. Eischen" wrote:
> We don't provide locking for fd's any longer (I thought this was only in
> -current, but your results seem to indicate otherwise). If we did, only
> one thread would wake up. The mistake in your sample seems to be that
> you're having all threads block on the same fd
other
> simple way to do this...
>
> Incidentally, I'm still curious, what does the POSIX spec say all this?
It doesn't cover poll(2). You can see what Single Unix Specification
(version 2) has to say at:
http://www.opengroup.org
The URL for poll(2) is below, but I'm not sure if yo
In article <[EMAIL PROTECTED]>,
Jonathan Chen <[EMAIL PROTECTED]> wrote:
>
> Incidentally, I'm still curious, what does the POSIX spec say all this?
As far as I know, poll is not described by any POSIX standards.
John
--
John Polstra [EMAIL PROT
On Mon, Aug 13, 2001 at 01:18:52PM -0400, Daniel M. Eischen wrote:
> We don't provide locking for fd's any longer (I thought this was only in
> -current, but your results seem to indicate otherwise). If we did, only
> one thread would wake up. The mistake in your sample seems to be that
> you're
Jonathan Chen wrote:
> Yesterday marked my first attempt at mixing poll() with pthreads.
> Needless to say, things did not work out the way I wanted them to. So, I
> began the task of finding out the behaviors of various OSes to see if my
> code would run fine on them. For your r
Yesterday marked my first attempt at mixing poll() with pthreads.
Needless to say, things did not work out the way I wanted them to. So, I
began the task of finding out the behaviors of various OSes to see if my
code would run fine on them. For your reference and amusement, my results
and
Thanks to all who answered my question about
libpcap and pthreads. I forgot to say that I want
to have the answer on the same question for
OpenBSD and NetBSD (for all *BSD, which
my port sysutils/ipa supports), but the answer for
FreeBSD is enough.
An idea to call pcap_dispatch() in a separate
t; On Wed, Jul 18, 2001 at 04:27:39PM +0400, Andrey Simonenko wrote:
> > Is it possible to use libpcap with pthreads?
> > (I want to use just pcap_dispatch() function)
>
> I very much doubt so. It's not possible to use it in any kind of
> multithreaded applications,
> > Is it possible to use libpcap with pthreads?
> > (I want to use just pcap_dispatch() function)
>
> I very much doubt so. It's not possible to use it in any kind of
> multithreaded applications, even with select() scenarios.
That's a BPF problem, not a libpcap
Privjet Andrey,
On Wed, Jul 18, 2001 at 04:27:39PM +0400, Andrey Simonenko wrote:
> Is it possible to use libpcap with pthreads?
> (I want to use just pcap_dispatch() function)
I very much doubt so. It's not possible to use it in any kind of
multithreaded applications, even
Hi all,
Is it possible to use libpcap with pthreads?
(I want to use just pcap_dispatch() function)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
allocation.
The above process is then run on top of a single pthreads
thread. With the newer pthreads libraries, this code nolonger
works:
Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at
line ? in file
/usr/src/lib/libc_r/uthread/uthread_jmp.c (er
On Sun, May 20, 2001 at 08:05:19AM -0400, Bill Abt wrote:
> Yeah, your right about slot. It should be allocated off the heap... Hmm,
> that would probably explain a few inconsistencies we've seen as well.
> Thanks
>
> As far as incorporating your changes into the release, sure!!! Another
>
* Arthur Munn <[EMAIL PROTECTED]> [010401 20:09] wrote:
> hello all, I was told by a friend that FreeBSD 5.0 is going to be sporting
> *real* pthreads, I was immediatley very excited and I want to know if this
> is true, if anyone knows I would really like to have it verified
On Sun, Apr 01, 2001 at 11:09:15PM -0400, Arthur Munn wrote:
> hello all, I was told by a friend that FreeBSD 5.0 is going to be sporting
> *real* pthreads, I was immediatley very excited and I want to know if this
> is true, if anyone knows I would really like to have it verified/
hello all, I was told by a friend that FreeBSD 5.0 is going to be sporting
*real* pthreads, I was immediatley very excited and I want to know if this
is true, if anyone knows I would really like to have it verified/dismissed.
thanks
On Sat, Mar 17, 2001 at 09:55:34AM +0100, Titus von Boxberg wrote:
> Hi,
>
> I just read your reply in the hackers mailing list regarding c++
> exceptions.
>
> Does that mean that now (or from release 4.3 on) the base system
> g++ is bugfixed regarding SIGSEGVs with c++ exceptions?
Bug, which f
Hi,
I just read your reply in the hackers mailing list regarding c++
exceptions.
Does that mean that now (or from release 4.3 on) the base system
g++ is bugfixed regarding SIGSEGVs with c++ exceptions?
What causes the bug in exception handling?
Why does the packaged g++ work?
Thanks in advance
I'm wondering if anyone has the time or inclination to take a look at a fix
for PR bin/25110. We're having problems using a freshly-built 4.2-stable
box (technically 4.3 rc at this point), and the bug is still present.
I'm not sure how many people would see this problem (we see it because we
hav
On Sun, 4 Mar 2001, Jordan DeLong wrote:
> On Sun, Mar 04, 2001 at 11:08:51AM +, Jordan DeLong wrote:
> > clone() wont count against the per uid process limit, right?
> actually I just realized it'd be incredibly stupid for clone not to
> count against the per uid process limit
It does the
> disadvantagous on SMP machines. I found a port of the linux pthreads, but it
> > uses rfork() to create the new threads...
> >
> > Anyway; I was curious if a clone() call is in the works for freebsd 5.0? And
>
> see rfork_thread(3). A pthreads implementation using it is
> Actually, clone() returns to your program with the stack fixed up
> so that you don't crash immediately, FreeBSD has a way of doing
> this, it's documented in the manpages and through disucssion on
> the mailing lists.
>
> --
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Yes, I k
I was
> > > looking it over and noticed that the pthread library is green; which is
> > > disadvantagous on SMP machines. I found a port of the linux pthreads, but it
> > > uses rfork() to create the new threads...
> > >
> > > Anyway; I was curiou
library is green; which is
> > disadvantagous on SMP machines. I found a port of the linux pthreads, but it
> > uses rfork() to create the new threads...
> >
> > Anyway; I was curious if a clone() call is in the works for freebsd 5.0? And
> > if not, is there much interest in g
On Sun, 4 Mar 2001, Jordan DeLong wrote:
> Hey; I've got a question about the pthread implementation on freebsd. I was
> looking it over and noticed that the pthread library is green; which is
> disadvantagous on SMP machines. I found a port of the linux pthreads, but it
>
> disadvantagous on SMP machines. I found a port of the linux pthreads, but it
> > uses rfork() to create the new threads...
>
> Why do you think that clone syscall on Linux is any different than rfork with
> appropriate parameters on FreeBSD?
>
> > Anyway; I wa
On 04-Mar-2001 Jordan DeLong wrote:
> Hey; I've got a question about the pthread implementation on freebsd. I was
> looking it over and noticed that the pthread library is green; which is
> disadvantagous on SMP machines. I found a port of the linux pthreads, but it
> uses
* Jordan DeLong <[EMAIL PROTECTED]> [010304 09:27] wrote:
> Hey; I've got a question about the pthread implementation on freebsd. I was
> looking it over and noticed that the pthread library is green; which is
> disadvantagous on SMP machines. I found a port of the linux pth
Hey; I've got a question about the pthread implementation on freebsd. I was
looking it over and noticed that the pthread library is green; which is
disadvantagous on SMP machines. I found a port of the linux pthreads, but it
uses rfork() to create the new threads...
Anyway; I was curious
You are absolutely right, that `inline' shouldn't have been there. My bad.
It works now - thanks!
John
On Sat, 10 Feb 2001 15:51:35 -0800 (PST), Jean-Marc Zucconi wrote:
> > John Wilson writes:
>
> > -
> > my_new.cc
> > -
>
> > #include
> > #include
>
1 - 100 of 164 matches
Mail list logo
