Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #79507 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2021-05-16 18:10 +0200 |
| Last post | 2021-05-18 15:14 -0700 |
| Articles | 20 on this page of 249 — 76 participants |
Back to article view | Back to comp.lang.c++
Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-16 18:10 +0200
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-16 10:54 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-16 20:01 +0200
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-16 11:29 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 08:20 +0200
Re: Niuce C++14-feature MrSpook_f4zl13qm@8lfoe01ih4ebku.com - 2021-05-17 09:26 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 12:52 +0200
Re: Niuce C++14-feature MrSpook_yMgsa7x5@3ifr32ivepk32ia.org - 2021-05-17 11:29 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 13:42 +0200
Re: Niuce C++14-feature MrSpook_zSl@bw3y07so7dr3go2x.tv - 2021-05-17 13:31 +0000
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-17 19:53 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-18 05:39 +0200
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-17 22:33 -0700
Re: Niuce C++14-feature MrSpook_sey@tad.gov.uk - 2021-05-17 07:42 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 10:58 +0000
Re: Niuce C++14-feature MrSpook_vj8xvznaud@d16tgqd.co.uk - 2021-05-17 11:32 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 12:03 +0000
Re: Niuce C++14-feature MrSpook_gT9q@x057vr3tuoe9s_ht3c.net - 2021-05-17 13:18 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 14:02 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 16:36 +0000
Re: Niuce C++14-feature MrSpook_rtfm7b8w@g403t8gw2b59awtit.tv - 2021-05-17 14:54 +0000
Re: Niuce C++14-feature Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-17 10:37 -0700
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-18 06:47 +0000
Re: Niuce C++14-feature MrSpook_w2uom3_k07@47j.ac.uk - 2021-05-18 07:30 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-18 10:31 +0000
Re: Niuce C++14-feature MrSpook_axe6hb@rq6ypc_knzvwr9.ac.uk - 2021-05-18 15:11 +0000
Re: Niuce C++14-feature Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-18 16:57 -0700
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-19 04:53 +0000
Re: Niuce C++14-feature Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-05-18 13:08 +0100
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-18 17:10 +0200
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-18 11:56 -0400
Re: Niuce C++14-feature Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-18 16:56 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-18 22:05 -0700
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-19 12:01 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-24 10:54 +0000
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-24 14:51 -0400
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-19 05:02 +0000
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-19 10:07 -0400
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-19 15:16 +0200
Re: Niuce C++14-feature Spud@nowheresville.org - 2021-05-19 07:19 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 00:53 -0700
Re: Niuce C++14-feature MrSpook_pl1c1bg7i@7sxv4z8mvmyz_.ac.uk - 2021-05-19 08:28 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:34 -0700
Re: Niuce C++14-feature MrSpook_6efnqt73nm@nyyte.com - 2021-05-19 08:44 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:50 -0700
Re: Niuce C++14-feature MrSpook_54rouunX@x37ixhgx27ymvhwc5.net - 2021-05-19 09:31 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:39 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:46 -0700
Re: Niuce C++14-feature MrSpook_nkfcgvl@7o616.biz - 2021-05-20 08:23 +0000
Re: Niuce C++14-feature Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-20 12:38 +0300
Re: Niuce C++14-feature MrSpook_5Xl@m9q7d5ux5tl8o5.co.uk - 2021-05-20 14:38 +0000
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-20 17:43 +0000
Re: Niuce C++14-feature MrSpook_dg01t9p2@m0m4iuefk1x.edu - 2021-05-21 09:16 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 13:38 +0200
Re: Niuce C++14-feature MrSpook_L1peqs_@c81ltrsr_gfoo1.co.uk - 2021-05-21 13:39 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 15:46 +0200
Re: Niuce C++14-feature MrSpook_km@gfepxabk0g_ytn7ta.net - 2021-05-21 14:48 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 17:03 +0200
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-21 14:15 +0000
Re: Niuce C++14-feature MrSpook_6f@fypmp_.biz - 2021-05-21 14:57 +0000
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-21 15:05 +0000
Re: Niuce C++14-feature "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-21 09:42 -0700
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-21 14:44 +0100
Re: Niuce C++14-feature MrSpook_4ptu0Yl4x9@2q77bsgmv.edu - 2021-05-21 14:47 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 05:31 +0200
Re: Niuce C++14-feature MrSpook_va6psV1d@w5lywejmkchyss0h4d.gov - 2021-05-21 09:24 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 13:33 +0200
Re: Niuce C++14-feature MrSpook_md3@zi2k.com - 2021-05-21 13:32 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 15:43 +0200
Re: Niuce C++14-feature MrSpook_zq3a8xxm@t9c1d7aq5dby4al.gov.uk - 2021-05-21 14:44 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 17:07 +0200
Re: Niuce C++14-feature MrSpook_hjgci2iT0@qtinm1mgdu.info - 2021-05-21 16:12 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 18:18 +0200
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-21 16:25 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 18:36 +0200
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-22 16:18 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-22 16:25 +0200
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-22 08:44 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-22 17:49 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 05:50 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 21:32 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 06:40 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 22:07 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 22:08 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 07:46 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:12 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:19 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:20 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:22 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:27 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:30 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:32 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:35 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:38 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:41 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:44 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:49 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:50 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:52 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:54 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:56 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:59 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:03 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:04 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:09 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:11 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:34 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:36 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:38 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:39 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:43 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:46 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:55 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:00 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:02 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:05 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:07 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:08 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:10 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:32 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:33 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:34 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:37 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:40 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:53 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:55 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:58 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:01 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:04 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:07 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:10 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:01 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:30 -0700
Re: Niuce C++14-feature MrSpook_801o@21xmy7.gov.uk - 2021-05-24 08:31 +0000
Re: Niuce C++14-feature MrSpook_8_g@ef863gl0.eu - 2021-05-24 08:34 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 11:49 +0200
Re: Niuce C++14-feature MrSpook_9v@0v6uq5zonj66dteaq9.ac.uk - 2021-05-24 10:15 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 12:44 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 13:33 -0700
Re: Niuce C++14-feature MrSpook_cjz9@ngfllgqd.edu - 2021-05-25 09:02 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 12:54 +0200
Re: Niuce C++14-feature MrSpook_43zpj5@zrdy.biz - 2021-05-25 09:02 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 12:53 +0200
Re: Niuce C++14-feature MrSpook_m0gtwlu6_g@j_cyo9l9.edu - 2021-05-25 09:05 +0000
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-25 16:22 +0200
Re: Niuce C++14-feature MrSpook_wBhaki@w1dhf2q0pnagn57.eu - 2021-05-24 08:26 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 11:51 +0200
Re: Niuce C++14-feature MrSpook_rfg_f9lmv@xechfnrqs23y.com - 2021-05-24 10:17 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 12:45 +0200
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-24 13:42 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 13:54 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 14:19 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 15:02 +0200
Re: Niuce C++14-feature MrSpook_1shmhc5pEg@qedprf.biz - 2021-05-24 13:57 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 18:15 +0200
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-24 15:21 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 15:37 +0200
Re: Niuce C++14-feature MrSpook_61Z@avwe8ulg.co.uk - 2021-05-24 13:49 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 18:14 +0200
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-24 16:58 +0200
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-24 18:51 +0200
Re: Niuce C++14-feature MrSpook_o_4Ge4wpt@2iwg_s7sq47equu9a.edu - 2021-05-24 08:25 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 11:52 +0200
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-21 17:19 +0100
Re: Niuce C++14-feature MrSpook_3l@rsdtj2x7.gov - 2021-05-24 08:22 +0000
Re: Niuce C++14-feature MrSpook_f4@x4dcxggdi.eu - 2021-05-20 13:42 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-20 16:20 +0200
Re: Niuce C++14-feature Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-05-20 18:02 +0000
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-20 19:23 +0000
Re: Niuce C++14-feature Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-05-21 00:07 +0100
Re: Niuce C++14-feature MrSpook_db0ucj9V@o6t54wlnnja_.co.uk - 2021-05-21 09:24 +0000
Re: Niuce C++14-feature MrSpook_a102e@wnyqsthof.net - 2021-05-21 09:22 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:53 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:54 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 10:30 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:35 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:36 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:37 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 12:57 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:33 -0700
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-19 10:20 -0400
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 18:13 +0200
Re: Niuce C++14-feature Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-19 10:09 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 13:28 +0200
Re: Niuce C++14-feature MrSpook_97@bxos5xe28b1i1n7kh.ac.uk - 2021-05-17 11:34 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 13:41 +0200
Re: Niuce C++14-feature MrSpook_b89m0or3@x1_pxvs4h8sxxi.gov.uk - 2021-05-17 13:29 +0000
Re: Niuce C++14-feature MrSpook_imhoou@kq9.ac.uk - 2021-05-17 15:53 +0000
Re: Niuce C++14-feature MrSpook_qg11H@ihwz2zmflqtcalb.gov.uk - 2021-05-17 16:06 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 18:21 +0200
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 16:38 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 17:58 +0200
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 14:03 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 16:37 +0000
Re: Niuce C++14-feature MrSpook_7kof@5x9.edu - 2021-05-18 07:27 +0000
Re: Niuce C++14-feature MrSpook_cOJ9@yr_8g_4nz.com - 2021-05-17 14:55 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 16:06 +0200
Re: Niuce C++14-feature MrSpook_tt7xetn_st@d3zd4ilmme.gov - 2021-05-17 14:56 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 17:20 +0200
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-18 17:20 +0200
Re: Niuce C++14-feature MrSpook_h2j5v@jq7cn18h8lm.com - 2021-05-18 15:35 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-18 17:57 +0200
Re: Niuce C++14-feature MrSpook_0by_disXi@2hd58e950gxh.eu - 2021-05-19 07:22 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 09:41 +0200
Re: Niuce C++14-feature MrSpook_ox7@4ieqo8ddusd3k1c8k.com - 2021-05-19 08:22 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 10:28 +0200
Re: Niuce C++14-feature MrSpook_4t1542s@nz48t.gov - 2021-05-19 08:40 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 12:54 +0200
Re: Niuce C++14-feature MrSpook_2ur@t65zb.com - 2021-05-19 11:08 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 13:11 +0200
Re: Niuce C++14-feature MrSpook_a9r7@vdgtzl3x.gov.uk - 2021-05-19 11:19 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 13:33 +0200
Re: Niuce C++14-feature MrSpook_of0j0vqHff@bap.com - 2021-05-19 13:29 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 16:17 +0200
Re: Niuce C++14-feature MrSpook_83b6en@o2cr9.ac.uk - 2021-05-19 14:57 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 17:49 +0200
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-19 17:41 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 19:55 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 14:02 -0700
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-19 21:06 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 14:12 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 14:13 -0700
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-20 12:16 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-20 12:31 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-20 12:33 +0200
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-20 18:37 +0200
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-20 13:10 -0400
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-20 17:56 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-20 20:26 +0200
Re: Niuce C++14-feature "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-05-20 19:50 -0700
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-20 14:35 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:54 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:58 -0700
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-19 11:16 +0200
Re: Niuce C++14-feature MrSpook_V1@aikd06tg1ez2i6hqi9.com - 2021-05-19 09:29 +0000
Re: Niuce C++14-feature Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-19 13:36 +0300
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 12:56 +0200
Re: Niuce C++14-feature MrSpook_w5c@g2nz1m_2f4r2g8wqvgfd.co.uk - 2021-05-19 11:07 +0000
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-19 10:34 -0400
Re: Niuce C++14-feature MrSpook_g1@mpi.com - 2021-05-19 14:55 +0000
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-19 16:15 +0000
Re: Niuce C++14-feature MrSpook_uc82glu@4o0o4n889yatl8.ac.uk - 2021-05-20 08:19 +0000
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-20 17:46 +0000
Re: Niuce C++14-feature MrSpook_mm9v3kgmmm@7_o9.co.uk - 2021-05-21 09:19 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-18 17:56 +0200
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-18 20:03 +0200
Re: Niuce C++14-feature MrSpook_fDx9@a3i3cdf7_.info - 2021-05-19 07:27 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 09:41 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-18 15:14 -0700
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-05-24 18:51 +0200 |
| Message-ID | <s8glje$lum$1@dont-email.me> |
| In reply to | #79917 |
On 24/05/2021 16:58, Manfred wrote: > On 5/24/2021 3:21 PM, David Brown wrote: >> On 24/05/2021 13:54, Bonita Montero wrote: >>> On 5/24/2021 3:21 PM, David Brown wrote: >>>> I'd agree that multi-threading is common today, and many applications >>>> that previously would have been written using forking will now use >>>> threads. In particular, anything that is supposed to work on Windows >>>> will prefer threads because Window's can't do forking, but on *nix the >>>> cost of forking is not usually much different from threading. >>> >>> Wrong, fork()ing is a pain in the ass when writing parallel >>> applications. Threading is a mangnitude easier to maintain. >> >> You come from a Windows world, where forking is not supported. In the >> *nix world, it's a different matter. >> >> There are pros and cons of both systems. Apache, for example, uses both >> on supported systems - it has multiple processes, each with multiple >> threads. >> >> I am not disagreeing with the idea that multi-threading is often more >> efficient than multi-processing, or that it is more common - I am merely >> disagreeing with your blanket generalisations about multi-threading >> /always/ being better and /always/ being used. >> > > The difference between fork and threads is not just how much they cost > in terms of resource consumption. Their memory model is obviously and > fundamentally different, and that's what drives the design choice > between them. > In the design of a service that must serve clients on different > connections it's very common that you don't /want/ to share the same > process space among all clients, because of a number of reasons ranging > from security to process robustness to design efficiency. sshd and > postgresql have been mentioned, other examples are file servers, wherein > the natural choice for synchronization is at the filesystem level. I'm > sure many more examples exist. > It's clearly no coincidence that fork() serves this kind of purpose > pretty well, and that it was designed this way in the *nix world. > > However the benefit of a multiprocess design is not only for server code. > Even in a single user scenario the design of a complex system with > dozens of tasks may very well choose a multiprocess solution especially > if system stability is a primary requirement, where you don't want a > fault in one function to compromise the whole system. > I've seen this happen even under Windows. A clear example of that last point would be browsers, where forking means that plugins, extensions, tabs, etc., can crash without bringing down the whole browser. It costs - especially in ram - but you get benefits from it.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_o_4Ge4wpt@2iwg_s7sq47equu9a.edu |
|---|---|
| Date | 2021-05-24 08:25 +0000 |
| Message-ID | <s8fnu2$1uof$1@gioia.aioe.org> |
| In reply to | #79696 |
On Fri, 21 May 2021 18:18:02 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >> You don't even know what I'm talking refering to do you? Having threads of >> a single application spread over multiple CPUs requires specialist hardware >> and can cause serious performance bottlenecks. ... > >The necessities of synchronization are the _same_ for fork()ing and >MT, i.e. you need to share memory at the same places in the code and >you need to synchronize also at the same places. But MT is more effi- Yes, congratulations. Thats why a few posts back - which naturally you didn't read or understand - I said for applications that DON'T require much or any synchronisation between code paths multi process is better. Eg user connections. >cient because of the shared address-space - a lot of synchronization >then doesn't need any kernel-aid - and easier to write. >Your knowledge is very superficial when it comes to parallelization ! Its amusing when people impart a chapter from compsci 101 as some profound piece of knowledge they're handing down from on high. :)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-24 11:52 +0200 |
| Message-ID | <s8ft12$a4g$3@dont-email.me> |
| In reply to | #79821 |
> Yes, congratulations. Thats why a few posts back - which naturally you > didn't read or understand - I said for applications that DON'T require much > or any synchronisation between code paths multi process is better. ... It's always better with threads, but it's only _feasible_ with fork()ing when you have simple patterns.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2021-05-21 17:19 +0100 |
| Message-ID | <20210521171938.000035fe@reddwarf.jmc> |
| In reply to | #79695 |
On Fri, 21 May 2021 16:12:43 +0000 (UTC) MrSpook_hjgci2iT0@qtinm1mgdu.info wrote: > On Fri, 21 May 2021 17:07:44 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > >>> Almost any application wich is parallel needs this. Because > > > >> No applications need multiple CPUs? Sure about that? > > > >Wer're talking about MT vs. fork()ing, dude. > > You don't even know what I'm talking refering to do you? Having > threads of a single application spread over multiple CPUs requires > specialist hardware and can cause serious performance bottlenecks. > The same restriction does not apply to multiprocess. Specialist hardware? LOL. You appear to have no clue as to how modern CPUs work or how operating systems are designed. Modern CPUs have MULTIPLE CORES with SHARED CACHES. > > >> Presumably have proof of this so please give a URL. > > > >I don't have to prove this. Having foked() app with the least > >coupling > > Yes you do. Now provide some proof or STFU. The fractally wrong often think they are right and EVERYBODY ELSE is wrong. > > >of the parallel processsing is much harder to write with fork()ing > >than with MT. Shared-memory, named pipes and semaphores are much > >more compli- cated to handle than a single shared address-space with > >simple mutexes and condition-variables. And even more: this kind of > >parallelism is usually more performant than forked() synchronization > >(f.e. consider that a uncontended mutex-lock is only about a few > >dozen cycles in a MT-environment). > > Nice cut and paste. > A) Stop using that idiotic made up word "performant". It doesn't make > you sound clever, more like a dumb sheep following the herd. "Performant" is a perfectly cromulent word, dear. > > B) As I already said if you could bloody read, not all execution > paths require close synchronisation but some DO require seperation of > memory and isolation from errors - eg ssh connections. You don't want > all user connections sharing the same memory in an application that > involves encrypted data or every user being kicked off if 1 thread > crashes you fucking mouth breathing moron! Word salad, dear. > > So guess what, sshd forks a new process per connection! > > Now spend the weekend getting a clue and dont bother replying until > you have one. Ah, a classic case of psychological project there, dear. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_3l@rsdtj2x7.gov |
|---|---|
| Date | 2021-05-24 08:22 +0000 |
| Message-ID | <s8fnnv$1s9e$1@gioia.aioe.org> |
| In reply to | #79697 |
On Fri, 21 May 2021 17:19:38 +0100 Mr Flibble <flibble@reddwarf.jmc> wrote: >On Fri, 21 May 2021 16:12:43 +0000 (UTC) >MrSpook_hjgci2iT0@qtinm1mgdu.info wrote: >> You don't even know what I'm talking refering to do you? Having >> threads of a single application spread over multiple CPUs requires >> specialist hardware and can cause serious performance bottlenecks. >> The same restriction does not apply to multiprocess. > >Specialist hardware? LOL. You appear to have no clue as to how modern >CPUs work or how operating systems are designed. Modern CPUs have >MULTIPLE CORES with SHARED CACHES. Nooooo!!! Say it ain't so!!! I'm talking about seperate CPUs gimp boy. >> Nice cut and paste. >> A) Stop using that idiotic made up word "performant". It doesn't make >> you sound clever, more like a dumb sheep following the herd. > >"Performant" is a perfectly cromulent word, dear. No, its just another nonsense word invented by tech bros when there are perfectly suitably other words or phrases to use. >> B) As I already said if you could bloody read, not all execution >> paths require close synchronisation but some DO require seperation of >> memory and isolation from errors - eg ssh connections. You don't want >> all user connections sharing the same memory in an application that >> involves encrypted data or every user being kicked off if 1 thread >> crashes you fucking mouth breathing moron! > >Word salad, dear. Oh bless, too complicated a concept?
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_f4@x4dcxggdi.eu |
|---|---|
| Date | 2021-05-20 13:42 +0000 |
| Message-ID | <s85ovi$1gpe$1@gioia.aioe.org> |
| In reply to | #79656 |
On Thu, 20 May 2021 12:38:37 +0300 Paavo Helde <myfirstname@osa.pri.ee> wrote: >20.05.2021 11:23 MrSpook_nkfcgvl@7o616.biz kirjutas: >> I was talking about multi process in general. If C++ supports threads why >> doesn't it support multi process too? My theory is because of the broken >> windows process model - any lowest common denominator API would be next to >> useless on unix. > >The issue with posix style process creation (fork()) is that it does not >play well with multithreading. Fork() creates a new process out of a >single thread in the old process, but inherits all the memory space of >the old process, including any mutex locks currently held by other >threads. As in the new process these other threads do not exist, nobody >will release these locks and the process can easily deadlock. Even if >the locks could be released somehow (e.g. by pthread_atfork() or >otherwise) the data structures they protected might easily remain in an >inconsistent state. This is a direct quote from "man fork": That may be so, but you could argue it the other way around - threads don't play nicely with multi process and the latter is far more useful as multi process can do everything that threading can do - albeit not as efficiently in some cases - but threading definately cannot do everything multi process can do. >Thus one may argue it's the posix process creation model which is broken >and does not fit well the current multithread-dominated software design. I disagree. The windows process model which starts a new process from the beginning each time with no state carried over (except for command line args) is extremely limited in its usefulness. Posix can do that plus fork at a given point with the new process being a carbon copy of the old one except for the return value from fork(). >One might try to limit multi-processing to single-thread programs only >and getting fork() to work in Windows, but in practice this is not I've been told, though I've never seen it in action, that the windows kernels can do something like fork() but the win32 API doesn't expose it. >possible, even the simplest Hello World program immediately gets invaded >by foreign threads created by antiviruses and shell extensions. I don't Sounds like Windows runtime is profoundly broken if that happens outside of the control of the program.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-20 16:20 +0200 |
| Message-ID | <s85r79$ddd$1@dont-email.me> |
| In reply to | #79661 |
> I disagree. The windows process model which starts a new process from the > beginning each time with no state carried over (except for command line args) > is extremely limited in its usefulness. Posix can do that plus fork at a given > point with the new process being a carbon copy of the old one ... This is good for nothing.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-05-20 18:02 +0000 |
| Message-ID | <jvxpI.109651$v3H9.22864@fx01.iad> |
| In reply to | #79656 |
On 2021-05-20, Paavo Helde <myfirstname@osa.pri.ee> wrote: > 20.05.2021 11:23 MrSpook_nkfcgvl@7o616.biz kirjutas: >> I was talking about multi process in general. If C++ supports threads why >> doesn't it support multi process too? My theory is because of the broken >> windows process model - any lowest common denominator API would be next to >> useless on unix. > > The issue with posix style process creation (fork()) is that it does not > play well with multithreading. Fork() creates a new process out of a > single thread in the old process, but inherits all the memory space of > the old process, including any mutex locks currently held by other > threads. As in the new process these other threads do not exist, nobody > will release these locks and the process can easily deadlock. Even if > the locks could be released somehow (e.g. by pthread_atfork() or > otherwise) the data structures they protected might easily remain in an > inconsistent state. This is a direct quote from "man fork": > > "After a fork() in a multithreaded program, the child can > safely call only async-signal-safe functions (see > signal-safety(7)) until such time as it calls execve(2)." > > So what we effectively get is pretty similar to the Windows process > creation model: a lot of complicated setup with limited functionality, > and a new fresh process started with a new executable. > > Thus one may argue it's the posix process creation model which is broken > and does not fit well the current multithread-dominated software design. > > One might try to limit multi-processing to single-thread programs only > and getting fork() to work in Windows, but in practice this is not > possible, even the simplest Hello World program immediately gets invaded > by foreign threads created by antiviruses and shell extensions. I don't > like this either, but there you are. Normaly one don't do threads and forks togather. Always was like that, except fork/exec (some execuatble) like cgi_bin in web server... > -- current job title: senior software engineer skills: x86 aasembler,c++,c,rust,go,nim,haskell... press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-05-20 19:23 +0000 |
| Message-ID | <_GypI.157715$OF5.47415@fx07.iad> |
| In reply to | #79668 |
Branimir Maksimovic <branimir.maksimovic@gmail.com> writes: >On 2021-05-20, Paavo Helde <myfirstname@osa.pri.ee> wrote: >> >> One might try to limit multi-processing to single-thread programs only >> and getting fork() to work in Windows, but in practice this is not >> possible, even the simplest Hello World program immediately gets invaded >> by foreign threads created by antiviruses and shell extensions. I don't >> like this either, but there you are. > >Normaly one don't do threads and forks togather. Always was like that, >except fork/exec (some execuatble) like cgi_bin in web server... When threads were first introduced to SVR4 (with SVR4.2MP), they added a 'forkall(2)' system call, which in addition to the normal fork(2) operations, would copy all the light-weight processes (LWP) which implemented the kernel threads. A user-level M:N thread model was implemented that used N LWPs and M user-level threads (where M doesn't necessarily need to match N). Linux never implemented that model (although green threads were close) chosing instead to use a light-weight process (clone) 1:1 model. Digital Unix had their own threading model (Dave Butenhof) which was in many ways the genesis of the Posix 1003.4 pthread interfaces.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2021-05-21 00:07 +0100 |
| Message-ID | <20210521000712.891cfc1e5a093c4727471df0@cvine--nospam--.freeserve.co.uk> |
| In reply to | #79670 |
On Thu, 20 May 2021 19:23:38 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Branimir Maksimovic <branimir.maksimovic@gmail.com> writes: > >On 2021-05-20, Paavo Helde <myfirstname@osa.pri.ee> wrote: > > >> > >> One might try to limit multi-processing to single-thread programs only > >> and getting fork() to work in Windows, but in practice this is not > >> possible, even the simplest Hello World program immediately gets invaded > >> by foreign threads created by antiviruses and shell extensions. I don't > >> like this either, but there you are. > > > >Normaly one don't do threads and forks togather. Always was like that, > >except fork/exec (some execuatble) like cgi_bin in web server... > > When threads were first introduced to SVR4 (with SVR4.2MP), they > added a 'forkall(2)' system call, which in addition to the normal > fork(2) operations, would copy all the light-weight processes (LWP) > which implemented the kernel threads. > > A user-level M:N thread model was implemented that used N LWPs and > M user-level threads (where M doesn't necessarily need to match N). > > Linux never implemented that model (although green threads were > close) chosing instead to use a light-weight process (clone) > 1:1 model. > > Digital Unix had their own threading model (Dave Butenhof) which > was in many ways the genesis of the Posix 1003.4 pthread > interfaces. This is more a posting to those who preceded you than to you: there is an irresoluble conflict about what you do when a multi-threaded process forks. There are only two approaches: you fork the process with all threads included, or you fork the process with one thread (the forking thread) included. Either approach leads to your code being in an undecidable state, because forking is asynchronous with respect to the non-forking threads. There is discussion of the issue (in connection with the useless attempt to square the circle with pthread_atfork()) by the man himself here: https://groups.google.com/g/comp.programming.threads/c/ThHE32-vRsg/m/3j-YICgSQzoJ So don't fork a multi-threaded process after other threads are running unless you intend to exec immediately after, and where you do intend to exec, do your setup (except for setting up pipes) in the forking thread before forking and not in the child. Where you definitely need multiple processes in a multi-threaded program, fork before you launch other threads and communicate with the child process via pipes. Then you will be OK.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_db0ucj9V@o6t54wlnnja_.co.uk |
|---|---|
| Date | 2021-05-21 09:24 +0000 |
| Message-ID | <s87u82$1mdp$1@gioia.aioe.org> |
| In reply to | #79671 |
On Fri, 21 May 2021 00:07:12 +0100 Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: >So don't fork a multi-threaded process after other threads are running >unless you intend to exec immediately after, and where you do intend to >exec, do your setup (except for setting up pipes) in the forking thread >before forking and not in the child. Where you definitely need multiple >processes in a multi-threaded program, fork before you launch other >threads and communicate with the child process via pipes. Then you >will be OK. The general approach to using threads+processes is you have a core process spawner and each child process then creates its own threads. You don't create the threads in the parent.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_a102e@wnyqsthof.net |
|---|---|
| Date | 2021-05-21 09:22 +0000 |
| Message-ID | <s87u5e$1l6u$1@gioia.aioe.org> |
| In reply to | #79670 |
On Thu, 20 May 2021 19:23:38 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >Linux never implemented that model (although green threads were >close) chosing instead to use a light-weight process (clone) >1:1 model. The original linux threading system was pretty poor, in that it used seperate processes behind the scenes gerry rigged together using shared memory and other types of IPC then presented via the posix thread API as a multi threading model. Which defeated the point of using threads - ie lightweight and quick to create and destroy. IIRC that got binned from kernel 2.6 and real threads were implemented.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-05-19 01:53 -0700 |
| Message-ID | <s82jll$u4t$2@gioia.aioe.org> |
| In reply to | #79608 |
On 5/19/2021 1:44 AM, MrSpook_6efnqt73nm@nyyte.com wrote: > On Wed, 19 May 2021 01:34:15 -0700 > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >> On 5/19/2021 1:28 AM, MrSpook_pl1c1bg7i@7sxv4z8mvmyz_.ac.uk wrote: >>> On Wed, 19 May 2021 00:53:41 -0700 >>> Presumably the same reason they're not part of the C language - C++ is a >>> cross platform language and some realtime kernel don't support futex's. >> >> Right. However, we can emulate an eventcount or futex in C++. > > You can't emulate OS level locking in a higher level context. > >>> Arguably even having built in threading support in C++ is a step too far. >> >> Why? > > Because some systems don't even support threads - eg PIC. > >>> After all, if it has threading why doesn't it have built in multi process >>> support too? >> >> Humm... > > Humm indeed. I suspect its because the win32 process model is profoundly > broken and since Windows dev was/is arguably the largest user base for C++ > they didn't see the point. > We can even go lower and emulate a waitset as a linked list of condvars with pure C++11.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-05-19 01:54 -0700 |
| Message-ID | <s82jnv$u4t$3@gioia.aioe.org> |
| In reply to | #79611 |
On 5/19/2021 1:53 AM, Chris M. Thomasson wrote: > On 5/19/2021 1:44 AM, MrSpook_6efnqt73nm@nyyte.com wrote: >> On Wed, 19 May 2021 01:34:15 -0700 >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >>> On 5/19/2021 1:28 AM, MrSpook_pl1c1bg7i@7sxv4z8mvmyz_.ac.uk wrote: >>>> On Wed, 19 May 2021 00:53:41 -0700 >>>> Presumably the same reason they're not part of the C language - C++ >>>> is a >>>> cross platform language and some realtime kernel don't support futex's. >>> >>> Right. However, we can emulate an eventcount or futex in C++. >> >> You can't emulate OS level locking in a higher level context. >> >>>> Arguably even having built in threading support in C++ is a step too >>>> far. >>> >>> Why? >> >> Because some systems don't even support threads - eg PIC. >> >>>> After all, if it has threading why doesn't it have built in multi >>>> process >>>> support too? >>> >>> Humm... >> >> Humm indeed. I suspect its because the win32 process model is profoundly >> broken and since Windows dev was/is arguably the largest user base for >> C++ >> they didn't see the point. >> > > We can even go lower and emulate a waitset as a linked list of condvars > with pure C++11. It would need to result in SCHED_OTHER, but okay, for the emulation.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-19 10:30 +0200 |
| Message-ID | <s82ibr$vt4$2@dont-email.me> |
| In reply to | #79598 |
> All criticisms are welcome. I can say, back when C/C++11 first came out, > why was there not an eventcount or futex like thread sync mechanism? These are facilities which aren't supplied by every operating-system but could be used to implement the synchronization-facilities C++11 provides. > Well, shit happens. The fun part is that they can be coded up in pure > C/C++11. Not ideal, but they can be coded. No, futexes need explicit kernel-support.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-05-19 01:35 -0700 |
| Message-ID | <s82ijq$fgr$2@gioia.aioe.org> |
| In reply to | #79602 |
On 5/19/2021 1:30 AM, Bonita Montero wrote: >> All criticisms are welcome. I can say, back when C/C++11 first came >> out, why was there not an eventcount or futex like thread sync mechanism? > > These are facilities which aren't supplied by every operating-system > but could be used to implement the synchronization-facilities C++11 > provides. > >> Well, shit happens. The fun part is that they can be coded up in pure >> C/C++11. Not ideal, but they can be coded. > > No, futexes need explicit kernel-support. Wel, true futex does, but it can be emulated.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-05-19 01:36 -0700 |
| Message-ID | <s82ilg$fgr$3@gioia.aioe.org> |
| In reply to | #79604 |
On 5/19/2021 1:35 AM, Chris M. Thomasson wrote: > On 5/19/2021 1:30 AM, Bonita Montero wrote: >>> All criticisms are welcome. I can say, back when C/C++11 first came >>> out, why was there not an eventcount or futex like thread sync >>> mechanism? >> >> These are facilities which aren't supplied by every operating-system >> but could be used to implement the synchronization-facilities C++11 >> provides. >> >>> Well, shit happens. The fun part is that they can be coded up in pure >>> C/C++11. Not ideal, but they can be coded. >> >> No, futexes need explicit kernel-support. > > Wel, true futex does, but it can be emulated. think about it for a moment. How would you create an eventcount or futex using pure C++11?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-05-19 01:37 -0700 |
| Message-ID | <s82ioe$fgr$4@gioia.aioe.org> |
| In reply to | #79605 |
On 5/19/2021 1:36 AM, Chris M. Thomasson wrote: > On 5/19/2021 1:35 AM, Chris M. Thomasson wrote: >> On 5/19/2021 1:30 AM, Bonita Montero wrote: >>>> All criticisms are welcome. I can say, back when C/C++11 first came >>>> out, why was there not an eventcount or futex like thread sync >>>> mechanism? >>> >>> These are facilities which aren't supplied by every operating-system >>> but could be used to implement the synchronization-facilities C++11 >>> provides. >>> >>>> Well, shit happens. The fun part is that they can be coded up in >>>> pure C/C++11. Not ideal, but they can be coded. >>> >>> No, futexes need explicit kernel-support. >> >> Wel, true futex does, but it can be emulated. > > think about it for a moment. How would you create an eventcount or futex > using pure C++11? It can be done: https://youtu.be/1G13KzEJqBw ;^) Also, here is some code for an eventcount: Read all: https://groups.google.com/g/lock-free/c/acjQ3-89abE/m/dbNokvg-nRIJ
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-19 12:57 +0200 |
| Message-ID | <s82qva$rcf$3@dont-email.me> |
| In reply to | #79604 |
>>> Well, shit happens. The fun part is that they can be coded up in pure >>> C/C++11. Not ideal, but they can be coded. >> No, futexes need explicit kernel-support. > Wel, true futex does, but it can be emulated. No one needs pure futexes - they're used to build other synchronization -facilities on top of them. Some of them are those you have in mind wich could be used to emulate a futex.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-05-19 13:33 -0700 |
| Message-ID | <s83sm5$kkj$1@gioia.aioe.org> |
| In reply to | #79619 |
On 5/19/2021 3:57 AM, Bonita Montero wrote: >>>> Well, shit happens. The fun part is that they can be coded up in >>>> pure C/C++11. Not ideal, but they can be coded. > >>> No, futexes need explicit kernel-support. > >> Wel, true futex does, but it can be emulated. > > No one needs pure futexes - they're used to build other synchronization > -facilities on top of them. Some of them are those you have in mind wich > could be used to emulate a futex. Right. However, it can be a fun exercise to emulate them in pure C/C++ using atomics, membars, and condvars. However, the emulated futex cannot be used for interprocess work, only intraprocess.
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web