- The effectiveness of C++14 - 1 Update
- www.equestionanswers.com - C,C++, VC++,MFC,COM,DCOM, DLL question and answers for interviews and self-study - 4 Updates
- "In defense of printf" - 1 Update
- std::thread...too little, too late? - 9 Updates
| legalize+jeeves@mail.xmission.com (Richard): Jan 02 06:58PM [Please do not mail me a copy of your followup] Melzzzzz <mel@zzzzz.com> spake the secret code >By the time C++98 compilers go out of usage I will be retired... If you are still using a C++98 compiler at this point, you have noone to blame but yourself. C++11 compilers are widely and easily available and C++14 is mostly implemented by the major tool chains. <http://clang.llvm.org/cxx_status.html> <https://gcc.gnu.org/projects/cxx1y.html> <http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Juha Nieminen <nospam@thanks.invalid>: Jan 02 12:21PM > Also imo best return is: return EXIT_SUCCESS; > I dont like return 0; :) Doesn't the C++ standard state that a returnless main() will return EXIT_SUCCESS by default? Thus it's ok to not write any return at all (unless you want to return an error code). --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 02 12:39PM On Fri, 2015-01-02, Juha Nieminen wrote: > Doesn't the C++ standard state that a returnless main() will return > EXIT_SUCCESS by default? Thus it's ok to not write any return at all > (unless you want to return an error code). On the other hand, few programs can honestly say "I will always succeed" ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 02 10:34AM -0600 On Fri, 2 Jan 2015 12:21:50 +0000 (UTC), Juha Nieminen >Doesn't the C++ standard state that a returnless main() will return >EXIT_SUCCESS by default? Thus it's ok to not write any return at all >(unless you want to return an error code). C++98 will return zero (which is like, but not identical to, EXIT_SUCCESS). C99 and later are the same, but C89 allows the form (no return at the end of main), but leaves the actual value returned to the OS undefined. |
| Barry Schwarz <schwarzb@dqel.com>: Jan 02 10:21AM -0800 On Fri, 2 Jan 2015 12:21:50 +0000 (UTC), Juha Nieminen >Doesn't the C++ standard state that a returnless main() will return >EXIT_SUCCESS by default? Thus it's ok to not write any return at all >(unless you want to return an error code). If by OK you mean well defined, then yes. If you mean good style or compliant with organization standards, maybe at best. -- Remove del for email |
| Juha Nieminen <nospam@thanks.invalid>: Jan 02 11:59AM >> output into that string, and those further modules... and so on. > So, if you need appending to a string, why don't you use > std::string::append()? Why streams? Because streams are much simpler given that I need to append values of different types, and later read them from that string (which is also much easier with streams). --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 01 05:33PM -0600 Ian Collins <ian-news@hotmail.com> wrote in news:cgluj1Fm4qrU10 > spawn multiple processes. Most servers that use multiple processes > simply clone an instance of themselves to do work. The parent handles > incoming requests and manages its children. If the parent process is multithreaded, then fork() clones a single thread only. This means that in a multithreaded program, about the only thing the child can do after fork is exec. Otherwise, all garbage from the other threads like allocated memory and locked mutexes remains in the new process. Locked mutexes (e.g. in the memory allocator) may easily cause the child to be deadlocked. Ensuring that other threads are in a clean state would need tedious synchronization and may kill the hoped-for performance. This is relevant for the multithread+multiprocess solution proposed by somebody upthread. Also, I believe third-party libraries are starting to make more use of multiple threads. As more and more programs become multithreaded, the possibilities to apply fork-no-exec scenario will be reduced. |
| Ian Collins <ian-news@hotmail.com>: Jan 02 12:47PM +1300 Paavo Helde wrote: > process. Locked mutexes (e.g. in the memory allocator) may easily cause the > child to be deadlocked. Ensuring that other threads are in a clean state > would need tedious synchronization and may kill the hoped-for performance. Admittedly the situation can become messy, but POSIX does provide pthread_atfork() to help manage forking in the threaded application. See the rationale at http://pubs.opengroup.org/onlinepubs/000095399/ -- Ian Collins |
| woodbrian77@gmail.com: Jan 01 06:08PM -0800 On Thursday, January 1, 2015 4:17:34 PM UTC-6, Ian Collins wrote: > The only difference I'm aware of between quick_exit use in C and C++ is > static destructors. http://www.cplusplus.com/reference/cstdlib/quick_exit/ That page says, "No object destructors are called." > quick_exit() and _Exit apply. There is a big difference between the > actions performed by calling exit and calling _Exit. quick_exit fills > the gap by providing a means to perform limited cleanup. I'm not finding much documentation on quick_exit on C sites. I've only found some documentation for it on C++ sites. I'm using https://duckduckgo.com to search. Brian Ebenezer Enterprises http://webEbenezer.net |
| Ian Collins <ian-news@hotmail.com>: Jan 02 03:48PM +1300 >> static destructors. > http://www.cplusplus.com/reference/cstdlib/quick_exit/ > That page says, "No object destructors are called." Quite. C doesn't have them... >> the gap by providing a means to perform limited cleanup. > I'm not finding much documentation on quick_exit on C sites. > I've only found some documentation for it on C++ sites. My platform doesn't have it, but FreeBSD does: http://www.unix.com/man-page/freebsd/3/QUICK_EXIT/ -- Ian Collins |
| Melzzzzz <mel@zzzzz.com>: Jan 02 04:49AM +0100 On Fri, 02 Jan 2015 15:48:06 +1300 > > I've only found some documentation for it on C++ sites. > My platform doesn't have it, but FreeBSD does: > http://www.unix.com/man-page/freebsd/3/QUICK_EXIT/ Hm, I am on Linux it has quick_exit in libc but it is nowhere documented... |
| Ian Collins <ian-news@hotmail.com>: Jan 02 04:58PM +1300 Melzzzzz wrote: > Hm, I am on Linux it has quick_exit in libc but it is nowhere > documented... Indeed, the professional quality of Linux man pages! It's been in glibc for quite a while. -- Ian Collins |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 02 12:40AM -0600 Ian Collins <ian-news@hotmail.com> wrote in > Admittedly the situation can become messy, but POSIX does provide > pthread_atfork() to help manage forking in the threaded application. > See the rationale at http://pubs.opengroup.org/onlinepubs/000095399/ Thanks for the link! However, I gather the only thing what pthread_atfork () achieves is to make the "tedious synchronization" more manageable or even possible. And the rationale still suggests to call exec() very soon after fork(). It seems it's mostly just concerned with how to avoid deadlocks in (arguably buggy) old programs which call unsafe library routines between fork() and exec(). Cheers Paavo |
| Ian Collins <ian-news@hotmail.com>: Jan 02 07:47PM +1300 Paavo Helde wrote: > after fork(). It seems it's mostly just concerned with how to avoid > deadlocks in (arguably buggy) old programs which call unsafe library > routines between fork() and exec(). I see it as more of a tool for multi-threaded library writers to manage the sate of their library around a fork. The library writers don't have any control over how their code gets used. -- Ian Collins |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 02 02:20AM -0600 Ian Collins <ian-news@hotmail.com> wrote in > I see it as more of a tool for multi-threaded library writers to > manage the sate of their library around a fork. The library writers > don't have any control over how their code gets used. Yes, but it's still more like a kludge. Imagine a library which makes use of an internal threadpool of N threads. Now the pre-fork hook is basically supposed to send a stop signal to the whole threadpool and wait until all N threads have completed whatever task they were doing. Seems not lightweight at all. And what about the post-fork hook? Should it recreate the threadpool or not? If there is exec() coming up soon this would not make any sense, and if no exec is coming it might make sense for the library to terminate N/2 threads in the parent and start N/2 threads in the child. However, there is no good way for the library to know that (the application and other libraries may call fork() from multiple places in parallel, some followed by exec, some not). Cheers Paavo |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment