Switch to DuckDuckGo Search
   December 19, 2018
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31

Toggle Join/Part | bottom
[00:00:11] <future28> Heh, let me see. thanks for the sanity
[00:00:12] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has quit IRC (Quit: zzz ...)
[00:01:13] <future28> If that *is* the case, why would the one intepretation work as expected? Is .data() possibly pointing elsewhere to &xxx[0] ?
[00:01:21] <future28> Or just undefined behavior
[00:01:50] <Aleric> Another possibility is that in both cases you do the same thing: print uninitialized memory - but because the code is different, in one case you get garbage and in the under case the content of the memory is still what it was before it was freed.
[00:02:54] <future28> Ah right, that makes perfect sense. I'm looking into it now, should find out soon enough
[00:03:11] <Aleric> To investigate that you could print it twice, once with data() and once with &vec[0], immediately after another. That should print the same thing imho (unless the printing itself allocate memory that overwrites it for the second case.. :/)
[00:03:27] *** jan64 <jan64!~jan64@79.191.201.95.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 240 seconds)
[00:04:46] <Aleric> Printing the contents of a vector that you just moved would do this I suppose.
[00:06:12] <future28> Can someone remind me of the best practices for move constructors? if I have m_obj with a member vector m_vec, does m_obj(std::vector<uint32_t> incoming) : m_vec(std::move(incoming)) {}; look normal?
[00:06:13] *** wootehfoot <wootehfoot!~wootehfoo@unaffiliated/wootehfoot> has quit IRC (Read error: Connection reset by peer)
[00:06:22] <future28> I know it hides the move but I'm not too worried about that
[00:06:48] <future28> Gee I am probably butchering this, I should really brush up
[00:07:17] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has joined ##C++-general
[00:07:50] <Aleric> Man, I have this annoying situation: Thread A creates a Socket object. That is not associated with file descriptor until it tries to connect(), that function calls socket(2) to get a new fd and then connect(2) to start the connect. Only after that the fd is registered with libev to monitor it for writeability, but only when there is something to write of course.
[00:08:35] <Aleric> So, thread A creates Socket, calls socket(2), then connect(2) then registers the fd with libev and then checks if the output buffer associated with the Socket object is empty.
[00:09:58] <Aleric> In the meantime another thread can already attempt to write to the Socket (to the output buffer) however... So, that's UB - I don't have a mutex that protects the streambuf (output buffer) from concurrent access (and I don't want that either really).
[00:10:05] *** virmaha <virmaha!42aa6301@gateway/web/freenode/ip.66.170.99.1> has quit IRC (Ping timeout: 256 seconds)
[00:11:16] <Aleric> Now the ONLY reason why I check if there is data in the obuffer immediately after registering the new fd is for the case where thread A creates the Socket - THEN writes data to the obuffer - and then tries to connect(). In that case the fd needs to be monitored immediately.
[00:13:13] <Aleric> Or well, I guess some other thread could write to the Socket anyway... in that case I'd have to check if there is something in the buffer too...
[00:14:09] *** bewbs <bewbs!~bewbs@100.34.1.114> has quit IRC (Remote host closed the connection)
[00:14:37] *** bewbs <bewbs!~bewbs@100.34.1.114> has joined ##C++-general
[00:15:15] *** Timesheet <Timesheet!~Timesheet@50.237.31.82> has quit IRC (Quit: Leaving)
[00:15:18] *** Jester2 <Jester2!~jester2@znc.epiphyte.network> has quit IRC (Quit: ZNC - https://znc.in)
[00:15:38] <future28> Hi again, here is a MWE for my given problem: https://ideone.com/8jC1Dl
[00:16:12] <future28> Look at the move constructor with suspicion, perhaps the emplace_back
[00:16:48] <Aleric> Erm... I think my original design was that the output buffer doesn't need a mutex because it doesn't makes sense to allow two threads to even try and write to it simultaneously; even WITH a mutex, you'd still possibly get garbled stuff. It's logical to assume that there will be some synchronization method provided by the user that assures that data is written sequentially - aka, by a single thread. On the other hand, reading that buffer (and checking
[00:16:49] <Aleric> if it is empty) DOES happen concurrently... so I guess I need to add a mutex somewhere :/
[00:17:33] <kalven> Aleric: so is this just to detect the case where it happens to be called concurrently or actually to deal with it in a meaningful way?
[00:17:53] <kalven> what happens with the data if the connect fails?
[00:18:10] <Aleric> Then it is discarded
[00:18:36] <Aleric> you just get an error event - and whatever you wrote might or might not have been written to the server - the connection is closed.
[00:19:08] <Aleric> Ok, not connecting is detected as such - in that case you know that nothing was passed to the server of course.
[00:20:03] <Aleric> No, the problem is that I have a single thread that writes to a streambuf, while concurrently another thread needs to read from it. I need to figure out how to make a std::streambuf interface threadsafe for that :/
[00:20:27] <Aleric> Checking if the buffer is empty does:
[00:20:56] *** jan64 <jan64!~jan64@79.191.201.95.ipv4.supernova.orange.pl> has joined ##C++-general
[00:21:18] *** bewbs <bewbs!~bewbs@100.34.1.114> has quit IRC (Ping timeout: 250 seconds)
[00:21:27] <Aleric> input_streambuf->gptr() == pptr()
[00:21:42] <Aleric> those are two different streambufs
[00:21:58] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has joined ##C++-general
[00:22:50] *** bewbs <bewbs!~bewbs@100.34.1.114> has joined ##C++-general
[00:22:51] *** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has joined ##C++-general
[00:22:57] <Aleric> So, I need a mutex that locks whatever gptr() there is wherever it is used, and the same for pptr, and all other pointers. A single streambuf has three pointers - I have two streambufs, so that's six pointers. Not sure if I need 6 mutexes...
[00:23:18] <Aleric> Lemme help future28 first...
[00:23:42] <Aleric> future28: line 16 doesn't need to end on a semi-colon :/
[00:23:57] <Aleric> Also the move there is plainly weird.
[00:24:18] <Aleric> Maybe you meant to use std::vector<uint32_t>&& in line 15?
[00:24:23] <future28> Aleric: Haha right... But that wouldn't matter, right? I understand that move may be strange, should I pass the move in to the emplace_back?
[00:24:39] *** vdamewood <vdamewood!~vdamewood@unaffiliated/vdamewood> has joined ##C++-general
[00:25:45] <future28> Aleric: Sorry, I don't recall what that is - would that allow me to correctly take ownership of a (possibly) temporary vector such that it wont be free'd once I lose scope?
[00:27:31] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has quit IRC (Quit: zzz ...)
[00:30:07] <Aleric> I don't see what that would work.. and it works.
[00:30:22] <Aleric> I wrote it to std::cout instead, and it does just work: https://ideone.com/USc20R
[00:30:36] *** chjk6x_ <chjk6x_!~chjk6x@105.158.88.85> has joined ##C++-general
[00:30:46] <g0> so.. post the nonworking code instead?
[00:30:48] <Aleric> I don't see why that wouldn't* work...
[00:32:22] <Aleric> future28: Now you make a copy of the vector to 'vec' of line 15, which is then moved to some_vector. But your intention is to move temp from line 25 into some_vector, without the extra copy.
[00:32:37] <Aleric> Then you need the two && in line 15.
[00:32:39] <g0> future28: your "move" logic is incomplete (but not detrimental at this point - it will just make a copy)
[00:32:46] *** chjk6x <chjk6x!~chjk6x@196.65.130.119> has quit IRC (Ping timeout: 246 seconds)
[00:33:10] <Aleric> yes, it is not the problem. It works as is with out or without removing that copy
[00:33:14] <future28> Right, so what would the correct code look like for that move?
[00:33:34] <future28> I realize it's not a problem but I need to run this code across many (large) vectors so copying is bad for my runtime
[00:34:26] *** Jester2 <Jester2!~jester2@znc.epiphyte.network> has joined ##C++-general
[00:34:39] *** kedziorno <kedziorno!~kedziorno@176.100.198.27.studiowik.net.pl> has quit IRC (Quit: Reconnecting)
[00:34:41] *** alphawarrior <alphawarrior!uid243905@gateway/web/irccloud.com/x-xzlwqeinqwzoweji> has quit IRC (Quit: Connection closed for inactivity)
[00:34:44] <g0> future28: my_data(uint32_t v, std::vector<uint32_t> &&vec)
[00:34:53] <g0> future28: plus all_data.emplace_back(x, std::move(temp))
[00:34:53] *** kedziorno <kedziorno!~kedziorno@176.100.198.27.studiowik.net.pl> has joined ##C++-general
[00:35:35] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has joined ##C++-general
[00:35:37] <Aleric> refresh https://ideone.com/USc20R
[00:36:02] *** chjk6x_ <chjk6x_!~chjk6x@105.158.88.85> has quit IRC (Ping timeout: 250 seconds)
[00:36:17] <Aleric> ok, what g0 said :p... I'm going to concentrate on my problem :p
[00:36:50] <g0> if there's garbage, run valgrind or ASAN/UBSAN
[00:36:59] <future28> Right, fair enough. I will check valgrind to see what's going wrong with the other problem
[00:37:07] <future28> Thanks for the help g0 and Aleric
[00:38:48] *** m_ben <m_ben!~m_ben@unaffiliated/m-ben/x-5917362> has quit IRC (Quit: WeeChat 2.3)
[00:39:30] *** vdamewood <vdamewood!~vdamewood@unaffiliated/vdamewood> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[00:46:17] <Aleric> You gotta love SO... https://stackoverflow.com/questions/9963413/istream-and-ostream-with-shared-streambuf-mutually-thread-safe-for-duplex-i-o
[00:54:49] <kalven> Aleric: what's wrong?
[00:55:54] *** aombk2 <aombk2!~aombk@unaffiliated/aombk> has joined ##C++-general
[00:58:06] <Aleric> What you mean?
[00:58:16] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[00:58:26] <kalven> "gotta love SO..." sounded like sarcasm
[00:58:35] <Aleric> I just said I love SO, cause it has the same question already listed... Unfortunately, the answers aren't helpful :(.
[00:58:42] <Aleric> It wasn't sarcasm
[00:59:10] *** wjagels <wjagels!~quassel@70.23.7.153> has quit IRC (Quit: Bye!)
[00:59:31] *** aombk3 <aombk3!~aombk@unaffiliated/aombk> has quit IRC (Ping timeout: 244 seconds)
[00:59:40] *** wjagels <wjagels!~quassel@70.23.7.153> has joined ##C++-general
[01:00:57] <kalven> have you looked at how asio does it?
[01:01:34] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has joined ##C++-general
[01:02:11] *** wjagels <wjagels!~quassel@70.23.7.153> has quit IRC (Client Quit)
[01:02:51] *** wjagels <wjagels!~quassel@70.23.7.153> has joined ##C++-general
[01:02:59] *** wjagels <wjagels!~quassel@70.23.7.153> has quit IRC (Client Quit)
[01:03:12] *** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has quit IRC (Read error: Connection reset by peer)
[01:03:57] *** bewbs <bewbs!~bewbs@100.34.1.114> has quit IRC (Read error: Connection reset by peer)
[01:04:21] *** wjagels <wjagels!~quassel@70.23.7.153> has joined ##C++-general
[01:05:40] *** bewbs <bewbs!~bewbs@100.34.1.114> has joined ##C++-general
[01:06:06] *** gehn <gehn!gehn@gateway/vpn/privateinternetaccess/gehn> has quit IRC (Quit: Leaving)
[01:06:39] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has quit IRC (Quit: zzz ...)
[01:11:17] <Aleric> Does asio even support streaming to a streambuf with one thread, while another thread flushes it to the corresponding fd?
[01:12:26] *** jthomas1 <jthomas1!~jthomas@ec2-35-166-162-151.us-west-2.compute.amazonaws.com> has quit IRC (Ping timeout: 250 seconds)
[01:13:04] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has joined ##C++-general
[01:13:23] <kalven> I don't know, that's what I suggested you find out :)
[01:13:31] <kalven> I know it has a streambuf
[01:14:06] <kalven> but maybe it's completely synchronous. the examples have the user call flush
[01:14:08] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has quit IRC (Client Quit)
[01:16:39] *** ppf <ppf!~ppf@unaffiliated/ppf> has quit IRC (Quit: ZNC 1.6.3+deb1ubuntu0.1 - http://znc.in)
[01:18:04] *** bewbs <bewbs!~bewbs@100.34.1.114> has quit IRC (Remote host closed the connection)
[01:18:25] *** bewbs <bewbs!~bewbs@100.34.1.114> has joined ##C++-general
[01:21:16] *** Arlen0 <Arlen0!~Arlen0@cpe-24-243-33-35.satx.res.rr.com> has joined ##C++-general
[01:21:26] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has joined ##C++-general
[01:22:01] <Aleric> I don't see any locking...
[01:22:03] <Aleric> https://github.com/chriskohlhoff/asio/blob/master/asio/include/asio/basic_streambuf.hpp#L233
[01:23:03] *** Arlen0 <Arlen0!~Arlen0@cpe-24-243-33-35.satx.res.rr.com> has quit IRC (Client Quit)
[01:23:09] <Aleric> That code "looks like" the code I have for my StreamBuf now; it just does what needs to be done, but there is no mutex anywhere.
[01:23:17] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[01:23:25] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[01:23:27] *** ppf <ppf!~ppf@unaffiliated/ppf> has joined ##C++-general
[01:24:10] <kalven> why do you need that second thread btw? is it to make the writer nonblocking?
[01:25:15] *** mujjingun <mujjingun!~park@pool-108-16-89-53.phlapa.fios.verizon.net> has joined ##C++-general
[01:25:15] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has joined ##C++-general
[01:25:25] <Aleric> Of course %-)
[01:25:44] <Aleric> The whole library is about being 100% non-blocking for every thread.
[01:26:43] <Aleric> If I don't see all my core use 100% cpu then I'm going to look into cache line interference or something - there is no other reason that any thread would slow down otherwise.
[01:26:55] <Aleric> but not there for a long time :p
[01:27:42] <kalven> how do you throttle things if the writer produces data much faster than the socket can consume?
[01:28:08] <Aleric> I do use mutexes, but they really should only be locked for extremely short times (ie 50 micro seconds), so that in 99.999% of the cases also that doesn't cause a delay really.
[01:28:20] <g0> that's bad advice
[01:28:36] <g0> there's practically no justification for 50µs.
[01:28:48] <Aleric> I mean nanoseconds, sorry
[01:28:57] <g0> that's impossible to achieve.
[01:29:08] *** bewbs <bewbs!~bewbs@100.34.1.114> has quit IRC (Remote host closed the connection)
[01:29:10] <g0> it's still a number pulled out of thin air with no relation to reality
[01:29:17] <Aleric> Not if you only lock for a few assembly instructions.
[01:29:24] <g0> for some people, 50µs is too much. For some applications and cases, 50µs is not enough.
[01:29:30] <Aleric> No, I measured it.
[01:29:30] *** bewbs <bewbs!~bewbs@100.34.1.114> has joined ##C++-general
[01:29:41] <g0> (not enough as in: it's ok to have ~100 ms)
[01:31:37] <Aleric> kalven: the buffers have a 'high water mark', if the size gets over that value then a write to the buffer failed and the fact that the buffer fails is propagated back all the way to the source, so that what ever is generating the data will slow down.
[01:31:45] <Aleric> fails*
[01:32:46] <kalven> Aleric: how is that signaled?
[01:32:51] <Aleric> It's an important ..whats the word.. heh "thing" :/ for me, that there is end-to-end flow control.
[01:34:38] <Aleric> As you know I come from the IRC world, and I've always thought and said that it's just wrong to buffer data until the buffer has ridiculous sizes. Networks are amazing now, but back in the day IRC often had lag between servers of MINUTES... The delay time being "size of data in the buffer" / "number of bytes processed per second".
[01:35:46] <Aleric> A huge buffer gives a huge lag - and the lag ramps up until the people on IRC literally couldn't communicate anymore and/or got so fed up that they left... finally causing the amount of incoming data to be reduced, so the buffer size could decrease again.
[01:35:54] <Aleric> But with that method everyone suffers.
[01:37:07] *** bewbs <bewbs!~bewbs@100.34.1.114> has quit IRC (Remote host closed the connection)
[01:37:48] <kalven> so how does the high water mark signalling done?
[01:37:50] <Aleric> What SHOULD be done is detect any increase of the buffers and when it ramps up beyond normal fluctuation (ie, 2 seconds lag at MOST), the clients should all be throttled - limit the maximum number of bytes per minute that everyone can send. That way people who chat just every now and then would not be harmed, and only have a lag of 2 seconds; while those who are flooding gets told: sorry, you're sending data too fast, try again
[01:38:57] <Aleric> At the moment it's not more than that when you try to write to a buffer, it fails with "buffer full". I don't have large applications like an ircd that is using the library yet :p.
[01:38:59] *** bewbs <bewbs!~bewbs@100.34.1.114> has joined ##C++-general
[01:39:28] <Aleric> But the frame work that I'm writing will be able to deal with it.
[01:39:49] <kalven> yeah but you're talking about streambufs, so I guess you're laying an iostream on top of it?
[01:39:52] <Aleric> Anyway... back to threadsafity of streambufs...
[01:40:20] <kalven> *layering
[01:40:48] <Aleric> I use the interface of a streambuf (the buffer itself is my own design) so that I can write to the buffer using an ostream, and read from it using istream, yes.
[01:41:42] <kalven> ok, so if I do: sock << x << y << z; and the buffer becomes full, how does the client deal with that?
[01:41:54] <Aleric> The main point of the buffer design is write once, read once, never move data.
[01:45:13] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has quit IRC (Quit: zzz ...)
[01:47:54] <Aleric> Hmm, had to look at the code for that. Using ostream causes overflow() to be called right?
[01:48:12] <Aleric> Seems that never fails... it just grows the buffer.
[01:48:35] <Aleric> You can call buffer_full() though to be responsible ;)
[01:49:26] <Aleric> The x, y and z should be (much) smaller than the max buffer size... If you actually write them like that it would be too annoying when it failed.
[01:49:49] <Aleric> So, you have to call buffer_full() to check if the buffer is already full before writing too much.
[01:50:16] <kalven> what if half of 'y' brings it over the mark?
[01:50:22] *** nshire <nshire!~nealshire@unaffiliated/nealshire> has joined ##C++-general
[01:50:30] <Aleric> Like I just said - it doesn't look at the mark.
[01:51:25] <kalven> I'm having problems reconciling your statements :)
[01:51:58] <Aleric> A buffer full water mark should be something like 8 times the average message length of the protocol in use. If you write x << y << z, then I consider that to be one message. So, if that goes over the mark then the result will contain something like 9/8th of what you consider too much, which is not a problem.
[01:52:27] *** mujjingun <mujjingun!~park@pool-108-16-89-53.phlapa.fios.verizon.net> has quit IRC (Ping timeout: 240 seconds)
[01:53:01] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has joined ##C++-general
[01:53:33] <Aleric> Ie, if you send (decodable) messages of 1kb, and set the water mark to 8kb - then you can write like crazy as in the above and make a buffer of 1 MB - but good code would check with bool buffer_full() way before you reach that size, and stop writing.
[01:54:09] <kalven> so it's up to the client to check before writing, and having a good idea of how big the serialized x, y and z are?
[01:54:11] <Aleric> On the other side, data read from a socket say - will read till the water mark and then stop reading the socket until the data in the buffer drops below the low water mark
[01:54:25] <Aleric> yes - or rather, of the protocol object.
[01:54:32] <Aleric> but that is probably provided by the user.
[01:55:02] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has quit IRC (Client Quit)
[01:55:06] <Aleric> You can do this:
[01:55:19] <Aleric> if (buf.buffer_full())
[01:55:22] <Aleric> // hold back
[01:55:24] <Aleric> else
[01:55:34] <Aleric> buf << x << y << z;
[01:55:52] <Aleric> or you could say "no, that is unfriendly horrible code - I want:
[01:56:08] <Aleric> try { buf << x << y << z; } catch()...
[01:56:31] <Aleric> blah - I think the former makes more sense :p. In the end the write needs to take responsibility one way or the other.
[01:56:38] <Aleric> writer*
[01:56:42] <kalven> well the problem is that you can't really signal the error in the middle of buf << x << y << z
[01:56:54] <Aleric> yup, so I don't
[01:57:45] <Aleric> Some "protocols" might have a high water mark as large as 1MB - that is still nothing compared to the RAM sizes people have these days - so I'm not worried to over the high water mark :p.
[01:58:04] <Aleric> to go* over
[01:58:11] <kalven> sure, but the source of the 'messages' may be an ssd
[01:58:45] <SlashLife> try { write_transaction w(buf); buf << x << y << z; w.commit(); } catch(...) ...
[01:58:49] <Aleric> That's a device - the library just stops monitoring the fd when the buffer runs full.
[01:59:30] <Aleric> If you don't call read(2) on the fd of the file on your ssd... then there is no new data :p
[02:00:06] *** jan64 <jan64!~jan64@79.191.201.95.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 250 seconds)
[02:00:19] <Aleric> That way it is "communicated" over a tcp socket thus: the consuming end stops reading the socket when it can't process the incoming data.
[02:00:35] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has joined ##C++-general
[02:00:37] <Aleric> As a result soon the fd on the other end won't be writable anymore.
[02:00:45] <Aleric> and the data stream stops
[02:01:06] *** de-facto <de-facto!~de-facto@gateway/tor-sasl/de-facto> has quit IRC (Quit: See you around.)
[02:01:22] <kalven> I know how it works, I'm talking about the api and it sounds like every time you use this iostream-based api, you have to (a) have a reasonable idea of the serialized size of the object you want to send, and (b) deal with retry logic
[02:01:22] *** de-facto <de-facto!~de-facto@gateway/tor-sasl/de-facto> has joined ##C++-general
[02:01:51] <Aleric> I use 8kB socket buffers (too)... You can change it, but that's what most likely they will be. So no huge buffers inbetween that lag everything
[02:02:11] <Aleric> yup
[02:02:42] <Aleric> But there is no alternative imho. What most (all?) other people do, is just have no high water mark at all. For the rest it is the same thing.
[02:03:15] <Aleric> No high water mark means you don't need to check if the buffer is full - nice - but the result is unpredictable large amounts of data in your buffers.
[02:03:35] *** mujjingun <mujjingun!~park@pool-108-16-89-53.phlapa.fios.verizon.net> has joined ##C++-general
[02:03:48] <Aleric> My approach is more difficult to code, but it will give a lot better user experience in the end.
[02:04:01] *** alexge50 <alexge50!~alexge50@188.27.4.168> has quit IRC (Read error: Connection reset by peer)
[02:04:26] *** bewbs <bewbs!~bewbs@100.34.1.114> has quit IRC (Ping timeout: 250 seconds)
[02:04:34] <kalven> the "strategy" of just discarding data once the buffer is truly full doesn't mesh at all with the iostream interface, so if the client is writing variable sized objects to this stream, I'd expect them to first stream it to a stringbuf, check if your stream can handle that much data and then send it
[02:04:51] <Aleric> You misunderstood what I said then.
[02:04:51] <kalven> because if you ever get into the situation where data has been discarde, you're kinda screwed
[02:04:58] <Aleric> I'm not discarding data :/
[02:05:44] <kalven> you said: "At the moment it's not more than that when you try to write to a buffer, it fails with "buffer full"."
[02:06:04] <SlashLife> Aleric: You could also use multiple stream buffers. Instead of writing to the target stream directly, you'd obtain a secondary stream with a separate stream buffer. If at the time of returning the buffer, its contents fit into the main stream buffer, they get transferred and the secondary buffer becomes obtainable again.
[02:06:14] <Aleric> out << x << y << z; always succeeds and writes to arbitrary sizes. I'm just saying that in practice it won't be dramatic with that single line. Before you do this 100,000 times in a loop you should check if the buffer is "full" though
[02:06:48] <Aleric> kalven: that's on the device side...
[02:06:53] <SlashLife> If they don't fit, they stay in the secondary buffer and the write is considered successful nontheless. The buffer will not be obtainable until the main buffer has run low enough to take on the extra data.
[02:07:17] *** kedziorno <kedziorno!~kedziorno@176.100.198.27.studiowik.net.pl> has quit IRC (Remote host closed the connection)
[02:07:19] <Aleric> Basically, it stop reading the fd when the buffer says it is full.
[02:07:44] <Aleric> Or maybe I said it wrong.. sorry. But no data is discarded in any case ;)
[02:07:45] <kalven> Aleric: right, so the user will end up doing: ostringstream buf; buf << x << y << z; string s= buf.str(); sock.can_accept(s.size()); sock << s;
[02:07:56] <SlashLife> You will have overhead, but that overhead will be limited to the largest "atomic" write you would do.
[02:07:59] <Aleric> noo
[02:08:10] <Aleric> That would be horrible :p
[02:08:42] <Aleric> They will do: if (!buf.buffer_buf()) buf << x << y << z;
[02:09:25] <kalven> Aleric: and what happens if the buffer becomes full in the middle of writing out y?
[02:09:32] <kalven> like, truly full.. superfull
[02:09:32] <Aleric> In english (and in practise) that will be something like: if there is less than 8 kB in the buffer NOW - then write 1 kB regardless of the resulting size.
[02:09:47] <Aleric> That's not possible...
[02:10:13] <kalven> but in the general case I might not know how big the serialized y is...
[02:10:15] <Aleric> I have 32 GB of ram - really truly superfull means your PC is out of memory - then all bets are off.
[02:10:26] <kalven> so it's going to grow unbounded? which one is it
[02:10:42] <Aleric> Well, it is more than 1 GB? Then I suggest you redesign your code and write y is smaller bits :p
[02:11:21] <Aleric> yup unbounded. BUT - in practise x y and z together will be MUCH MUCH smaller than the amount of free RAM -so there is no problem.
[02:11:47] <Aleric> And if that is not the case - ie, y is so huge that you literally get a failing malloc() then you do something wrong.
[02:12:11] *** bewbs <bewbs!~bewbs@pool-72-78-139-39.phlapa.fios.verizon.net> has joined ##C++-general
[02:12:24] <kalven> Aleric: ok, but you previously said "the buffers have a 'high water mark', if the size gets over that value then a write to the buffer failed" - this is why I got confused
[02:12:29] <Aleric> Hell, we're writing html or something... it's like that suddenly you find yourself writing a megabyte line.
[02:12:31] <kalven> now you're saying the write wont fail (modulo running out of ram)
[02:12:34] <Aleric> it's not*
[02:12:43] <Aleric> I said that all along :(
[02:12:55] *** mitch0 <mitch0!~mitch@78-131-116-226.pool.digikabel.hu> has quit IRC (Remote host closed the connection)
[02:13:07] <Aleric> except alll in the beginning, and I already said "Or maybe I said it wrong.. sorry. But no data is discarded in any case"
[02:13:36] <kalven> so writes to the buffer won't fail?
[02:13:37] <Aleric> The rest of the time I've said at least 10 times no that << y NEVER fails
[02:13:43] <Aleric> indeed
[02:13:47] <Aleric> not with ostream
[02:14:01] <kalven> ok
[02:14:16] <Aleric> There is another interface... :)
[02:15:10] <Aleric> I have three interfaces to the buffer: one of iostream, for raw buffer access (read and writing without using iostreams) and one that is used by the library to read/write from/to file descriptors.
[02:15:39] *** mitch0 <mitch0!~mitch@62-165-204-255.pool.digikabel.hu> has joined ##C++-general
[02:16:06] <Aleric> The latter reacts to full buffers to stop read the fd, and therefore stops writing more- until the buffer drops below a certain size then it starts to read the fd again.
[02:16:13] <Aleric> The raw access... I'd have to check.
[02:16:28] *** XCE <XCE!~XCE@206.189.64.126> has joined ##C++-general
[02:18:24] <Aleric> Nah, also doesn't have builtin checking.
[02:18:40] <Aleric> Guess you have to check if the buffer full yourself there too.
[02:19:30] <Aleric> I don't think it would make sense to add that check... You might as well call a separate function before writing. Easier than trying to write and then fail.
[02:23:11] *** cCkw <cCkw!~ejakuk@gateway/tor-sasl/cckw> has quit IRC (Quit: Leaving)
[02:26:07] *** tm <tm!~sinnlos@unaffiliated/tm> has quit IRC (Ping timeout: 240 seconds)
[02:31:37] *** Boobie <Boobie!~boobie@108-240-104-11.lightspeed.irvnca.sbcglobal.net> has joined ##C++-general
[02:33:35] *** dev1990 <dev1990!~dev@dynamic-62-87-248-64.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!)
[02:34:31] *** tomboy65 <tomboy65!~tomboy64@gateway/tor-sasl/tomboy64> has quit IRC (Ping timeout: 256 seconds)
[02:34:52] *** maartenBE <maartenBE!~maartenBE@ptr-fhe1cum20g6rkm9ftms.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 264 seconds)
[02:37:33] *** tomboy65 <tomboy65!~tomboy64@gateway/tor-sasl/tomboy64> has joined ##C++-general
[02:45:12] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[02:46:12] *** lh_mouse <lh_mouse!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[02:53:52] *** irrenhaus3 <irrenhaus3!~xenon@ip-37-201-6-177.hsi13.unitymediagroup.de> has quit IRC (Quit: Lost terminal)
[02:57:26] *** nucleargrave <nucleargrave!~nucleargr@c-73-150-253-137.hsd1.nj.comcast.net> has joined ##C++-general
[02:58:52] *** theVOguy <theVOguy!~RDM@218.0.246.121> has joined ##C++-general
[02:59:56] *** nucleargrave <nucleargrave!~nucleargr@c-73-150-253-137.hsd1.nj.comcast.net> has quit IRC (Client Quit)
[03:00:18] *** nucleargrave <nucleargrave!~nucleargr@c-73-150-253-137.hsd1.nj.comcast.net> has joined ##C++-general
[03:02:17] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has quit IRC (Quit: zzz ...)
[03:03:37] *** Xiti <Xiti!~Xiti-@unaffiliated/xiti> has quit IRC (Quit: Xiti)
[03:03:55] *** maartenBE <maartenBE!~maartenBE@ptr-fhe1cum20g6rkm9ftms.18120a2.ip6.access.telenet.be> has joined ##C++-general
[03:07:46] *** kadoban <kadoban!~mud@unaffiliated/kadoban> has quit IRC (Quit: bye)
[03:08:11] *** Xiti <Xiti!~Xiti-@unaffiliated/xiti> has joined ##C++-general
[03:08:51] *** lh_ideapad <lh_ideapad!~lh_mouse@unaffiliated/lh-mouse/x-3986007> has joined ##C++-general
[03:09:55] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has joined ##C++-general
[03:14:42] *** thanzex <thanzex!b0cfc194@gateway/web/cgi-irc/kiwiirc.com/ip.176.207.193.148> has quit IRC (Ping timeout: 272 seconds)
[03:16:25] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[03:16:28] *** wPSvils <wPSvils!~PDevelope@83.243.92.42> has quit IRC (Read error: Connection reset by peer)
[03:16:30] *** quarterback <quarterback!~quarterba@160.238.72.214> has joined ##C++-general
[03:16:30] *** quarterback <quarterback!~quarterba@160.238.72.214> has quit IRC (Changing host)
[03:16:30] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[03:17:07] *** wPSvils <wPSvils!~PDevelope@83.243.92.42> has joined ##C++-general
[03:24:13] *** wPSvils1 <wPSvils1!~PDevelope@83.243.92.42> has joined ##C++-general
[03:24:42] *** wPSvils <wPSvils!~PDevelope@83.243.92.42> has quit IRC (Ping timeout: 244 seconds)
[03:26:27] *** maartenBE <maartenBE!~maartenBE@ptr-fhe1cum20g6rkm9ftms.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 268 seconds)
[03:26:45] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has joined ##C++-general
[03:28:45] *** Nokurn <Nokurn!~Nokurn@71-95-52-160.dhcp.rvsd.ca.charter.com> has quit IRC (Quit: ZNC 1.7.1 - https://znc.in)
[03:29:07] *** Nokurn <Nokurn!~Nokurn@71-95-52-160.dhcp.rvsd.ca.charter.com> has joined ##C++-general
[03:30:29] *** davr0s <davr0s!~textual@host109-155-175-220.range109-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[03:33:33] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined ##C++-general
[03:33:45] *** wjagels <wjagels!~quassel@70.23.7.153> has quit IRC (Ping timeout: 250 seconds)
[03:34:33] *** mujjingun <mujjingun!~park@pool-108-16-89-53.phlapa.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds)
[03:38:53] *** jthomas1 <jthomas1!~jthomas@c-98-202-237-95.hsd1.ut.comcast.net> has joined ##C++-general
[03:42:34] *** wjagels <wjagels!~quassel@70.23.7.153> has joined ##C++-general
[03:42:42] *** wjagels <wjagels!~quassel@70.23.7.153> has quit IRC (Remote host closed the connection)
[03:44:05] *** jthomas1 <jthomas1!~jthomas@c-98-202-237-95.hsd1.ut.comcast.net> has quit IRC (Ping timeout: 246 seconds)
[03:44:22] *** wjagels <wjagels!~quassel@70.23.7.153> has joined ##C++-general
[03:47:24] *** wjagels <wjagels!~quassel@70.23.7.153> has quit IRC (Client Quit)
[03:47:31] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Quit: Leaving)
[03:51:47] *** Unarelith <Unarelith!~Quent4234@static-176-158-117-112.ftth.abo.bbox.fr> has quit IRC (Ping timeout: 240 seconds)
[03:52:27] *** josephnoir <josephnoir!~josephnoi@2600:1700:e680:7060:30d7:b118:e86d:d583> has quit IRC (Quit: zzz ...)
[03:52:34] *** wjagels <wjagels!~quassel@2001:470:8ba4:101:ff:60ff:fea9:3a62> has joined ##C++-general
[03:55:27] *** kitsunenokenja <kitsunenokenja!~kitsunech@68.91.220.96> has quit IRC (Ping timeout: 240 seconds)
[03:57:10] *** quarterback <quarterback!~quarterba@160.238.72.214> has joined ##C++-general
[03:57:10] *** quarterback <quarterback!~quarterba@160.238.72.214> has quit IRC (Changing host)
[03:57:10] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has joined ##C++-general
[04:00:14] *** Roughy <Roughy!~mdaw45ns@188.126.203.78> has quit IRC (Quit: Meadow Fresh milk)
[04:01:51] *** wjagels_ <wjagels_!~quassel@2001:470:8ba4:101:ff:60ff:fea9:3a62> has joined ##C++-general
[04:01:51] *** wjagels_ <wjagels_!~quassel@2001:470:8ba4:101:ff:60ff:fea9:3a62> has quit IRC (Client Quit)
[04:02:02] *** wjagels <wjagels!~quassel@2001:470:8ba4:101:ff:60ff:fea9:3a62> has quit IRC (Read error: Connection reset by peer)
[04:02:07] *** wjagels_ <wjagels_!~quassel@2001:470:8ba4:101:ff:60ff:fea9:3a62> has joined ##C++-general
[04:02:21] *** theVOguy <theVOguy!~RDM@218.0.246.121> has left ##C++-general ("see you later")
[04:02:50] *** zap0 <zap0!~zap0@14-201-222-143.tpgi.com.au> has joined ##C++-general
[04:06:56] *** shfil <shfil!uid293885@gateway/web/irccloud.com/x-mqjqajfqhmbtwlux> has quit IRC (Quit: Connection closed for inactivity)
[04:11:16] *** maartenBE <maartenBE!~maartenBE@ptr-fhe1cum20g6rkm9ftms.18120a2.ip6.access.telenet.be> has joined ##C++-general
[04:18:48] *** wPSvils <wPSvils!~PDevelope@83.243.92.42> has joined ##C++-general
[04:19:04] <Captain_Crow> i seen some things mentioning apple deprecating opencl, will that affect all platforms or just apple?
[04:20:04] *** wPSvils1 <wPSvils1!~PDevelope@83.243.92.42> has quit IRC (Ping timeout: 250 seconds)
[04:29:17] *** Lord_of_Life <Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362> has quit IRC (Ping timeout: 244 seconds)
[04:30:50] <kalven> just their platforms
[04:32:00] *** Lord_of_Life <Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362> has joined ##C++-general
[04:35:22] *** quarterback <quarterback!~quarterba@unaffiliated/quarterback> has quit IRC (Read error: Connection reset by peer)
[04:36:56] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Remote host closed the connection)
[04:37:06] *** eadthem <eadthem!~eadthem@pdpc/supporter/active/eadthem> has joined ##C++-general
[04:38:36] *** maartenBE <maartenBE!~maartenBE@ptr-fhe1cum20g6rkm9ftms.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 268 seconds)
[04:42:23] *** batman_nair <batman_nair!~batman_na@111.92.74.160> has joined ##C++-general
[04:43:42] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[04:45:18] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined ##C++-general
[04:46:04] *** Codyer <Codyer!~user@x4dbc4dba.dyn.telefonica.de> has quit IRC (Ping timeout: 250 seconds)
[04:46:57] *** purpleunicorn <purpleunicorn!~purpleuni@unaffiliated/purpleunicorn> has joined ##C++-general
[04:51:29] <Captain_Crow> what's the difference between global and local in opencl kernels?
[05:01:44] *** future28 <future28!~future@unaffiliated/future28> has quit IRC (Ping timeout: 272 seconds)
[05:04:55] *** Gyro <Gyro!~user@x4dbab9a3.dyn.telefonica.de> has joined ##C++-general
[05:05:47] *** Renari <Renari!~Renari@70.15.63.19> has joined ##C++-general
[05:06:37] <Captain_Crow> i see most opencl examples using global variables in a kernel and im not really clear on why
[05:17:16] *** XCE <XCE!~XCE@206.189.64.126> has quit IRC (Ping timeout: 250 seconds)
[05:20:29] *** maartenBE <maartenBE!~maartenBE@ptr-fhe1cum20g6rkm9ftms.18120a2.ip6.access.telenet.be> has joined ##C++-general
[05:23:18] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has quit IRC (Remote host closed the connection)
[05:23:26] *** npaperbot <npaperbot!~npaperbot@dodecahedron.m-ou.se> has joined ##C++-general
[05:23:56] *** fc5dc9d4_ <fc5dc9d4_!~quassel@p5B081F6D.dip0.t-ipconnect.de> has joined ##C++-general
[05:26:29] *** tm <tm!~sinnlos@unaffiliated/tm> has joined ##C++-general
[05:28:06] *** fc5dc9d4 <fc5dc9d4!~quassel@p5B081D2A.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 250 seconds)
[05:30:02] *** thaurwylth11 <thaurwylth11!~thaurwylt@2a03:f680:fff2::d2> has joined ##C++-general
[05:35:03] *** thaurwylth11 <thaurwylth11!~thaurwylt@2a03:f680:fff2::d2> has quit IRC (Ping timeout: 252 seconds)
[05:37:43] *** kadoban <kadoban!~mud@unaffiliated/kadoban> has joined ##C++-general
[05:42:17] <zap0> i think it's a requirement
[05:42:38] <zap0> there is no reason; other than that's just how it's done
[05:45:32] <Captain_Crow> ok, thanks for clarifying
[05:47:15] <zap0> global data does not typically get mangled in ways local vars can.
[05:47:32] <zap0> Captain_Crow, sometimes local vars can be illiminated compeltely.
top

   December 19, 2018
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31