From 6576223823148494558 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,314ebdf2ff957e27 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-04-16 12:50:59 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: allan_w@my-dejanews.com (Allan W) Newsgroups: comp.std.c++ Subject: Re: Why int main()? Date: Wed, 16 Apr 2003 19:50:58 +0000 (UTC) Organization: http://groups.google.com/ Lines: 104 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <7f2735a5.0304161137.6ba35561@posting.google.com> References: <3E9821CE.8AC8B8C6@web.de> <7f2735a5.0304141217.59268028@posting.google.com> <3E9D3169.4C28BE45@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1050522658 27650 10.0.0.1 (16 Apr 2003 19:50:58 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 16 Apr 2003 19:50:58 +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 195svo-0007Bp-00 for mail2news@news.news.demon.net; Wed, 16 Apr 2003 19:50:57 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id FAA26829; Thu, 17 Apr 2003 05:50:53 +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-NNTP-Posting-Date: 16 Apr 2003 19:37:52 GMT X-Spam-Status: No, hits=-9.7 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.41 Xref: archiver1.google.com comp.std.c++:18784 > > terekhov@web.de (Alexander Terekhov) wrote > > > In the next round, I'd probably try to make {thread::}main's return > > > type "application-chosen" -- other thread(s) (if any) could then join > > > and obtain whatever-return-value (if it's not void)... and adopt a > > > rather simple POSIX behavior of "passive exit" on last thread > > > termination. Oder? ;-) > Allan W wrote: > > That's assuming a lot. terekhov@web.de (Alexander Terekhov) wrote > Let's see... > > Let's assume that every conforming C++ compiler will have to support > > threads (a huge assumption!). > > Every conforming C++ implementation ALREADY supports "threads" -- one > thread per C++ program... or more than one... if it supports MULTIPLE > threads per C++ program. First, picking on nits of ambiguous language doesn't really clarify the issue or advance the discussion in any meaningful way. Furthermore, the word "threads" is plural... Second, it's not even true. Look in the existing C++ standard for the word "thread." You'll find it exactly once -- in 15.1/2 [except.throw], in the phrase "thread of control," where it talks about exception handlers. Clearly not a "thread" in the sense that you originally used it. > > Let's further assume that when one thread > > terminates, some other thread (at least the one that spawned it in the > > first place) is able to get the "return value," no matter how large > > that might be. > > > > 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. > > 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? > > But what happens if the program has only one thread, and it returns > > data of type customer? What will the OS do with a customer? > > The implementation will do nothing special other than destroying "a > customer" object. Two problems with this. First, you're suggesting that the return data is ignored. Why bother returning data if it's going to be ignored? The current int value seems more than sufficient -- precisely because it is NOT ignored on some OS's. Second, think about the technical complications. You said that the OS would destroy the customer object. Does that mean it runs the destructor? The rest of the program has shut down, and all other objects have been destroyed... what does it mean to destroy an object when the rest of the run-time system has closed? > > 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? > > or not; if not, > > it might need some indication of generally what went wrong. This > > sounds a lot like the integer scheme currently in use on all Unix > > http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-review-l&id=1355 > (Subject: Defect in XBD 3.297 Process Termination) > > > systems, and carefully cloned on almost all other systems (including > > the MSDOS-subsystem of all Microsoft Windows platforms). > > Thread cleanup aside, "passive exit" already works "just fine" on all > Microsoft Windows platforms. Well, why don't you simply try it? Hints: > ExitThread, _endthread, _endthreadex. But you can't use these on portable programs! --- [ 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 ]