Re: rfork() [was: Concept check]
In article <1d5c01bf5c42$1409d990$[EMAIL PROTECTED]> you wrote:
> You've got that backwards - fork() and vfork() can easily be implemented in
> terms of rfork() [in fact, I believe all three are implemented in terms of
> fork1() in the kernel]. rfork(RFMEM) means that the processes share all
> memory - current AND FUTURE. You could use minherit() before fork() to
> share current memory, but not future memory.
BTW, concerning rfork(RFMEM). Could somebody explain me, why the
following simple program is coredumping:
#include
#include
volatile int data=0;
int
main()
{
volatile int pid=0;
int status;
pid=rfork(RFPROC|RFMEM|RFCFDG);
if(pid==-1) {
perror("rfork");
exit(-1);
}
if(pid!=0) {
wait(&status);
printf("Data is %d\n",data);
} else
data=1;
}
---
The world is coming to an end. Please log off.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: rfork() [was: Concept check]
Matthew Dillon <[EMAIL PROTECTED]> wrote: > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the > :following simple program is coredumping: > You cannot call rfork() with RFMEM directly from a C program. You > have to use assembly (has anyone created a native clone() call yet > to do all the hard work?). > The reason is that rfork(RFMEM) does not give the new process a new > stack, so both the old and new processes wind up on the same original > stack and stomp all over each other. Oh, well, I suspected something like that (from what I saw, trying to debug that small piece of code). Should it be at least mentioned in rfork(2)? --- You are only young once, but you can stay immature indefinitely. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Preemptiveness of FreeBSD threads
Hi, everybody!
First, I must say that this all concernes quite current
CURRENT (Jan 9 or so). I don't know if the same holds for
older versions.
I'm kind of puzzled.
I've a simple sample program (see at the bottom). It creates 10
threads with start function start_my_thread(), and then runs the
same function in main(). So, we have 11 threads doing the same job.
Function start_my_thread() just increments indefinitely counters
(each thread has its own counter).
Program, when killed with SIGINT, prints all counters and exits.
Now, as I understand, userspace threads in FreeBSD are preemptive.
So, though my 11 threads are all computational and do not do
any syscalls, sleeps, sched_yield, whatever -- newertheless,
the program should not be stuck in one thread. And it seems to
be sometimes true. But only sometimes!
Depending on the phase of the moon (it seems) sometimes my
program gives (after ^C):
^C
Thread 0x00: 0
Thread 0x01: 0
Thread 0x02: 0
Thread 0x03: 0
Thread 0x04: 0
Thread 0x05: 0
Thread 0x06: 0
Thread 0x07: 0
Thread 0x08: 0
Thread 0x09: 0
Thread 0x0a: 488133092
Which means that the main thread takes all the time. In the same
time 'ps -o command,sigcatch,nsignals,sig' gives:
COMMANDCAUGHT NSIGS PENDING
./a.out 14080002 3580
I suppose that means that the program has a handler for SIGPROF
installed (which I know is used to preempt threads). And the number
of delivered signals steadily goes up (which I suppose means that
SIGPROF's are actually delivered to program -- or else where does
that number of signals come from?).
Again, depending on the phase of the moon, sometimes program gives
quite normal result (from my point of view):
^C
Thread 0x00: 45894831
Thread 0x01: 42657716
Thread 0x02: 44529528
Thread 0x03: 45732187
Thread 0x04: 41087510
Thread 0x05: 39383485
Thread 0x06: 40748919
Thread 0x07: 39539107
Thread 0x08: 41414655
Thread 0x09: 38647395
Thread 0x0a: 43215354
This result is obtained for approximately the same runtime of the
program. The same picture from 'ps'. I'm starting to beleive that
the behaviour is dependent on the moon because two types of that
behaviour seem to be changing not randomly, but rather go in periods:
I can try for half an hour and receive the first, "wrong" result, and
then something changes somewhere, and for another hour I get the
second, "right" result.
Now, is there something obvious, what I don't see?
The sample program goes here:
#include
#include
#include
#define THRNUM 10
pthread_t threads[THRNUM];
int counters[THRNUM+1];
void*
start_my_thread(void* p)
{
int thread_num,i;
for(i=0;i
Re: Preemptiveness of FreeBSD threads
In article <[EMAIL PROTECTED]> you wrote: >> Now, as I understand, userspace threads in FreeBSD are preemptive. >> So, though my 11 threads are all computational and do not do >> any syscalls, sleeps, sched_yield, whatever -- newertheless, >> the program should not be stuck in one thread. And it seems to >> be sometimes true. But only sometimes! >> >> Depending on the phase of the moon (it seems) sometimes my >> program gives (after ^C): >> >> ^C >> Thread 0x00: 0 >> Thread 0x01: 0 >> Thread 0x02: 0 >> Thread 0x03: 0 >> Thread 0x04: 0 >> Thread 0x05: 0 >> Thread 0x06: 0 >> Thread 0x07: 0 >> Thread 0x08: 0 >> Thread 0x09: 0 >> Thread 0x0a: 488133092 > Hmm, I can't get this to occur with your test program. I've tried > it several times and the threads seem to be scheduled properly. > If you figure out how to repeat this without relying on phases of > the moon, I'd be interested in hearing how. That's what makes it most wierd for me -- I am not able to determine conditions when it gives a "wrong" result. I'll keep trying though. I also could probably compile libc_r with debug info and set a breakpoint somewhere in threads scheduler to see what's going on. Or, because it is time-related, it is not a good idea? Then printfs in libc_r -- will they work? Could you suggest a good place to start looking? As I said, it seems to go in periods -- for some time everything is normal, and then for some time -- bullshit :-\ You may try to repeat it after some time. It may also be hardware dependent (?) > Are you running NTP or changing the time? That idea also came to me, but no -- I don't have NTP, and I don't change the time. And as I said, the interrupts seem to keep being delivered to the process. > Dan Eischen > [EMAIL PROTECTED] --- After living in New York, you trust nobody, but you believe everything. Just in case. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preemptiveness of FreeBSD threads
In article <[EMAIL PROTECTED]> you wrote: > OK, with everyones help (well, waiting for the right time of day ;-)), I > was able to reproduce this. The initial threads last active time was > not getting initialized to a sane value, causing negative computations > of the threads timeslice depending on what time of day it was. Funny > thing was that I added this change several times, but each time I somehow > convinced myself that it wasn't needed. > Try this patch - you may have to hand apply it as my sources are not > yet up to date with the last round of changes that Jason made. > Dan Eischen > [EMAIL PROTECTED] [patch skipped] Yep, that seems to be it. No moon-dependent irregularities ;) Thanks! --- I really hate this damned machine I wish that they would sell it. It never does quite what I want But only what I tell it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyXXXX_r()
> hi, there! > > On Sat, 4 Aug 2001, Richard Seaman, Jr. wrote: > >> 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, but >> I don't think they are GPL, though you might want to do further >> research on their history if you use them. > > gethostbyxxx_r can be taken from bind 8 Yes, bind8 has them, as well as thread-safe resolver library. Unfortunately, FreeBSD's implementation is based on much older bind, and has wandered quite a long way from it (INET6, kqueue in res_send, etc.) So, to take bind8's implementation and modify it to match FreeBSD stuff would be quite painful IMHO. What I did to some extent mimics bind8's implementation. I just went from other direction -- took what FreeBSD has and applied some ideas from bind8. I just need couple more days to make it presentable. As for bind9 -- this has AFAIK totally rewritten resolver, which doesn't even resemble bind8. IMHO, to incorporate it into FreeBSD might take a tremendous effort. -- #include To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyXXXX_r()
In article <[EMAIL PROTECTED]> you wrote: > Please complete it, let me know when you submit the PR i'll try > to get it integrated. Ok, I submitted it: http://www.freebsd.org/cgi/query-pr.cgi?pr=29581 I tried to make as few changes as possible, but still diff is quite big IMHO. And changed only dns and files. I didn't do anything about nis -- mostly because I have no place to test it right now. Should be pretty simple to modify nis code too. -- #include To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
