in reply to Re^9: sysread/syswrite wrappers
in thread sysread/syswrite wrappers
File system caching is different, it's cached on OS level, so select will know about that and return "you can read".
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^11: sysread/syswrite wrappers
by BrowserUk (Patriarch) on Oct 12, 2016 at 19:49 UTC | |
So you have data to read, but select tells that you don't. Hm. This is a simple server, using non-block sockets, select and readline. It reads one line every 1/10th second ensuring the client will have finished and closed its end of the socket long before the server has read the first buffer load: And here a simple client that connects, writes 1 full 4k buffer load, then 2k and a distinct last line. If the select was returning eof before the buffer was emptied, you wouldn't see the distinct last line; but I always do!: Perhaps you can tell me what I'm doing 'wrong' to make it work? Or maybe the behaviour you describe is just a *nix thing. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] [select] |
by vsespb (Chaplain) on Oct 12, 2016 at 23:12 UTC | |
You see that it reads 6070 bytes right in one single read. After that it reads nothing, only writes to the screen. But select indeed returns right filehandle. Okay, end of stacktrace: select returns right filehandle again, and.. read returns EOF. So whole the time select was triggered by eof event (EOF is "can_read" too). Let's check. I added sleep before closing socket in client: and server hanged in the middle. So, without EOF event it stucks. New stacktrace: last select is not finished. means process stuck on it. | [reply] [d/l] [select] |
by BrowserUk (Patriarch) on Oct 12, 2016 at 23:42 UTC | |
select returns right filehandle again, and.. read returns EOF. So whole the time select was triggered by eof event (EOF is "can_read" too). In other words. IT WORKS! last select is not finished. means process stuck on it. You added a sleep to the client. Ergo: you created the exact scenario I warned you about in "And if your messages are not some exact multiple of 4K, the last line of every 4k block will be a partial message, and your wrapper will therefore block until the next 4k block has been filled and passed through, before that message will be completed.". The problem here is that you've latched onto something completely irrelevant, to distract from the fact that your OP code makes no sense. I was never suggesting that you should use <readline> & print; only that your code was exactly as vulnerable to the same issue -- an incomplete message, perpetual block -- as they are. Ie. If you added that sleep in the same place in the client code, and ran it against your OP sysread() wrapper, it blocks in exactly the same way! Your OP wrappers are useless, because they are vulnerable in exactly the same way as readline. And that's the point. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
by vsespb (Chaplain) on Oct 13, 2016 at 04:56 UTC | |
by BrowserUk (Patriarch) on Oct 13, 2016 at 06:39 UTC | |
|