From owner-freebsd-hackers Mon Jan 3 9:44:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 3C6B514CE1 for ; Mon, 3 Jan 2000 09:44:04 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id SAA17801; Mon, 3 Jan 2000 18:42:34 +0100 (CET) Date: Mon, 3 Jan 2000 18:42:33 +0100 From: Martin Cracauer To: Kip Macy Cc: Martin Cracauer , Steffen Merkel , freebsd-hackers@FreeBSD.ORG Subject: Re: Limited amount of variables in a multithreaded programm? Message-ID: <20000103184233.B17710@cons.org> References: <20000103173027.A61058@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from kip@lyris.com on Mon, Jan 03, 2000 at 09:00:05AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In , Kip Macy wrote: > What is wrong with malloc, then free? The stack size of threads on FreeBSD > is not that big, but there is no need to be declaring large auto > variables. Don't get me wrong, I have blown the stack on FreeBSD, and a > number of other OSs as well, but dynamic allocation has fixed it in all > cases. > Not sure if this is a serious question, especially considering that the size constants aren't got from the system but from ping(8) own guessing, but anyway: 1) Stack-allocated memory gets deallocated even when you drop out the routine other than an implicit return at the end. I.e. explicit return before the end of the procudure, longjmp'ing etc. 2) Stack-allocation is faster, since malloc needs bookkeeping while the stack "allocator" just grows or shrinks with no intermedeate allocation or freeing. In other words: What gets allocated last, will be free'ed first and that guarantee makes allocation a lot faster. I see the existance of an auto-growing stack as an indication how elegant the initial UNIX concurrency/procces model really is. Some people forget this in these days of Thread-hype. Another problem with the code in question is that it calls a function (getpid()) in variable initialization. Not advertised since it hardens debugging in case of problems further down. A few "const" here and there probably won't hurt either. FreeBSD's ping(8) is not a program that should be used for teaching C coding, threaded or not :-) Happy new year! Martin > On Mon, 3 Jan 2000, Martin Cracauer wrote: > > > In <001301bf5540$66b72610$0201a8c0@blade>, Steffen Merkel wrote: > > > int ping(struct in_addr *ipaddress){ > > > int s; /* socket handle for socket()*/ > > > int ident = getpid() & 0xFFFF; /* to ident ICMP message */ > > > int hlen; /* Header length */ > > > struct sockaddr_in *to; /* used to prepare tohost */ > > > struct sockaddr tohost; /* where to send ping - for sendto() */ > > > struct sockaddr fromhost; > > > struct ip *ip; > > > struct icmp *icp; /* used to generate icmp message */ > > > struct timeval *timetp; /* temporary time storage structure */ > > > struct timeval actimetp; /* store current time */ > > > u_char outmessage[MAXPACKET]; /* message we send */ > > > u_char inmessage[MAXPACKET]; /* message we receive */ > > > int i,ret; > > > > > > int mx_dup_ck = 1024; > > > return(10); /* I removed the ping-routine and replaced it with > > > * "return(10);" for testing reasons */ > > > } > > > > In FreeBSD, a normal process (fork/exec) has a stack that grows > > automatically as needed. You don't have this for threaded programs > > (and it is difficult to do). It's a save guess that this amount of > > stack allocation is more than the default stack size for a threaded > > program, and the stack cannot grow automatically. > > > > Did you check out the classic model before tangling with pthreads? :-) > > > > Martin > > -- > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > Martin Cracauer http://www.cons.org/cracauer/ > > BSD User Group Hamburg, Germany http://www.bsdhh.org/ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message