From 6676919681693024005 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,314ebdf2ff957e27 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-04-17 10:45:17 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: terekhov@web.de (Alexander Terekhov) Newsgroups: comp.std.c++ Subject: Re: Why int main()? Date: Thu, 17 Apr 2003 17:45:16 +0000 (UTC) Lines: 80 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <3E9E8B21.C1A5F841@web.de> References: <3E9821CE.8AC8B8C6@web.de> <7f2735a5.0304141217.59268028@posting.google.com> <3E9D3169.4C28BE45@web.de> <7f2735a5.0304161137.6ba35561@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1050601516 2352 10.0.0.1 (17 Apr 2003 17:45:16 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 17 Apr 2003 17:45:16 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 196DRj-0000bn-00 for mail2news@news.news.demon.net; Thu, 17 Apr 2003 17:45:15 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id DAA09519; Fri, 18 Apr 2003 03:45:12 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: comp.std.c++ X-Reply-To: terekhov@web.de X-Orig-NNTP-Posting-Host: ss05.co.us.ibm.com (32.97.110.70) X-Orig-X-Trace: fu-berlin.de 1050577726 2440490 32.97.110.70 (16 [158401]) X-Accept-Language: en X-Spam-Status: No, hits=-5.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Xref: archiver1.google.com comp.std.c++:18791 Allan W wrote: [...] > > > You're still making two even bigger assumptions. > > > 1) The process will live as long as *ANY* thread does. As opposed to, > > > "the process will live as long as the FIRST thread does." > > > > That's not the way how things {currently ;-)} work out there. > > Which is exactly my point. At least on some OS's (Microsoft Windows), > the initial thread is the "main" thread; when it exits, the program > terminates. But you said " 'passive exit' on last thread termination" > (quoted above) which is something else entirely. I said: Thread cleanup aside, "passive exit" already works "just fine" on all Microsoft Windows platforms. I've also asked you to simply try to exit initial/main thread and see whether it will cause process termination if the exiting thread isn't the last one. > > > > 2) Returning class data from the MAIN thread makes sense. > > > > Threads don't return "class data". Thread routines COULD "return" > > something (thread-exit "returns" including). Joinable [non-detached] > > threads allow to retrieve those objects. In C++, "manual detach" > > doesn't make much sense because it can be done "automatically" using > > smart thread-object pointers. Just like you can ignore any function > > return you'd be able to ignore any thread routine return. Again, > > nothing special here as well. > > The discussion was about return values from main(). Where are you > going with this? See the "examples" that I've posted to this thread. The second thread can also be joined (you'd need another "joiner" thread, though). [...] > > > The OS needs to know if the program ran successfully > > > > That's what "passive exit" on last thread termination is all about. > > But doesn't this break all existing programs? A *change* would break "some" programs, but not all. http://groups.google.com/groups?selm=pEu_9.187%24_l3.134%40news.cpqcorp.net -------------------------------------8<------------------------------------ >> > C99: >> > >> > "reaching the } that terminates the main function returns a >> > value of 0." >> >> Interesting. I missed that. Well, it's consistent with the POSIX "passive >> exit" when the last thread terminates. > > I wish they had defined it as "reaching the } that terminates > the main function shall terminate the initial thread with the > effect of executing pthread_exit(0)". ;-) That could be a problem, since POSIX lacks Sun's "daemon thread" attribute. That is, your change would rely on passive process exit rather than forcing immediate exit, and some applications would simply cease to exit at all. At least, for nonthreaded programs, it'd have the same effect as the C99 rule: the main thread is the only one, and its termination results in passive process termination with the status 0. -------------------------------------8<------------------------------------ Clearly, it would have to be another/additional "main() family" [preserving the "old"/current one] in order to NOT break some existing progs. regards, alexander. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]