Date: Mon, 3 Jan 2000 18:42:33 +0100 From: Martin Cracauer <cracauer@cons.org> To: Kip Macy <kip@lyris.com> Cc: Martin Cracauer <cracauer@cons.org>, Steffen Merkel <d_f0rce@gmx.de>, freebsd-hackers@FreeBSD.ORG Subject: Re: Limited amount of variables in a multithreaded programm? Message-ID: <20000103184233.B17710@cons.org> In-Reply-To: <Pine.SOL.4.05.10001030856260.5199-100000@luna.lyris.com>; from kip@lyris.com on Mon, Jan 03, 2000 at 09:00:05AM -0800 References: <20000103173027.A61058@cons.org> <Pine.SOL.4.05.10001030856260.5199-100000@luna.lyris.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <Pine.SOL.4.05.10001030856260.5199-100000@luna.lyris.com>, 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 <cracauer@cons.org> 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 <cracauer@cons.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000103184233.B17710>