Which buffers to flush?
I'm creating a client/server application in C where I re-use some existing code. Due to this, the server rather than the client is responsible for printing messages to the user. To achieve this, the server has opened stdout of the client by calling fopen() on '/proc//fd/1' and redirected its own stdout to this fd.
I wonder which buffers are involved when the server prints messages to understand what to flush?
The server obviously has to flush its own stdout, but will that be enough for the message to appear or will the output just end up at the buffer of the client's stdout?
Does the client also have to flush its stdout to make sure that the message is visible for the user?
Would a call to fsync() for both the server's and client's stdout make any difference?
The reason that I would like to fully understand which buffers are involved is that I've seen problems when the client's stdout is redirected to a file. I've read about the difference in line buffered and fully buffered output, so I suspect that the problem I have is related to the client's redirected stdout.
c
asked Nov 14 '18 at 12:56
BugsyBugsy
62
|
show 1 more comment
I'm creating a client/server application in C where I re-use some existing code. Due to this, the server rather than the client is responsible for printing messages to the user. To achieve this, the server has opened stdout of the client by calling fopen() on '/proc//fd/1' and redirected its own stdout to this fd.
I wonder which buffers are involved when the server prints messages to understand what to flush?
The server obviously has to flush its own stdout, but will that be enough for the message to appear or will the output just end up at the buffer of the client's stdout?
Does the client also have to flush its stdout to make sure that the message is visible for the user?
Would a call to fsync() for both the server's and client's stdout make any difference?
The reason that I would like to fully understand which buffers are involved is that I've seen problems when the client's stdout is redirected to a file. I've read about the difference in line buffered and fully buffered output, so I suspect that the problem I have is related to the client's redirected stdout.
c
asked Nov 14 '18 at 12:56
BugsyBugsy
62
The server can only do the trick if the client runs on the same machine. It’s a moderately putrid trick. The client should flush its standard output before sending a request to the server. If the server is using file stream I/O, then it needs to flush its redirected output before returning control to the client.
– Jonathan Leffler
Nov 14 '18 at 13:47
Yes they are obviously running on the same machine as I make use of the proc fs. I agree that it may not be a perfect solution, but due to the prerequisites of the project the server had to handle the output. I guess that the client has to flush in order to synchronize output with the server, but in this case the client will be completely silent so I guess it means that it not applicable? Based on what you say, I assume that output from the server will go straight to stdout or a file depending on what's defined in the client, without passing any buffer in the client(?).
– Bugsy
Nov 14 '18 at 14:44
The client code will never see any of the output from the server. It will go direct to the file or device that the client is using as standard output.
– Jonathan Leffler
Nov 14 '18 at 14:46
So I guess that as long as the server manage to flush it's buffer it will be safe for the client to close the file (redirected stdout)? In case anything is missing in the file, it wasn't properly output/flushed by the server?
– Bugsy
Nov 14 '18 at 15:05
Probably. Once the server has the file descriptor for the client’s standard output open, it shouldn’t matter if the client closes its output. And if only the server is writing to the client’s standard output, then any missing information is the server’s problem. (I still think this is an appallingly awful design. I’m explaining what I believe will happen, but I still think that the design is wrong — utterly the wrong way to approach the problem.)
– Jonathan Leffler
Nov 14 '18 at 15:13
|
show 1 more comment
I'm creating a client/server application in C where I re-use some existing code. Due to this, the server rather than the client is responsible for printing messages to the user. To achieve this, the server has opened stdout of the client by calling fopen() on '/proc//fd/1' and redirected its own stdout to this fd.
I wonder which buffers are involved when the server prints messages to understand what to flush?
The server obviously has to flush its own stdout, but will that be enough for the message to appear or will the output just end up at the buffer of the client's stdout?
Does the client also have to flush its stdout to make sure that the message is visible for the user?
Would a call to fsync() for both the server's and client's stdout make any difference?
The reason that I would like to fully understand which buffers are involved is that I've seen problems when the client's stdout is redirected to a file. I've read about the difference in line buffered and fully buffered output, so I suspect that the problem I have is related to the client's redirected stdout.
c
asked Nov 14 '18 at 12:56
BugsyBugsy
62
I'm creating a client/server application in C where I re-use some existing code. Due to this, the server rather than the client is responsible for printing messages to the user. To achieve this, the server has opened stdout of the client by calling fopen() on '/proc//fd/1' and redirected its own stdout to this fd.
I wonder which buffers are involved when the server prints messages to understand what to flush?
The server obviously has to flush its own stdout, but will that be enough for the message to appear or will the output just end up at the buffer of the client's stdout?
Does the client also have to flush its stdout to make sure that the message is visible for the user?
Would a call to fsync() for both the server's and client's stdout make any difference?
The reason that I would like to fully understand which buffers are involved is that I've seen problems when the client's stdout is redirected to a file. I've read about the difference in line buffered and fully buffered output, so I suspect that the problem I have is related to the client's redirected stdout.
c
c
asked Nov 14 '18 at 12:56
BugsyBugsy
62
asked Nov 14 '18 at 12:56
BugsyBugsy
62
asked Nov 14 '18 at 12:56
BugsyBugsy
62
asked Nov 14 '18 at 12:56
BugsyBugsy
62
asked Nov 14 '18 at 12:56
BugsyBugsy
62
62
The server can only do the trick if the client runs on the same machine. It’s a moderately putrid trick. The client should flush its standard output before sending a request to the server. If the server is using file stream I/O, then it needs to flush its redirected output before returning control to the client.
– Jonathan Leffler
Nov 14 '18 at 13:47
Yes they are obviously running on the same machine as I make use of the proc fs. I agree that it may not be a perfect solution, but due to the prerequisites of the project the server had to handle the output. I guess that the client has to flush in order to synchronize output with the server, but in this case the client will be completely silent so I guess it means that it not applicable? Based on what you say, I assume that output from the server will go straight to stdout or a file depending on what's defined in the client, without passing any buffer in the client(?).
– Bugsy
Nov 14 '18 at 14:44
The client code will never see any of the output from the server. It will go direct to the file or device that the client is using as standard output.
– Jonathan Leffler
Nov 14 '18 at 14:46
So I guess that as long as the server manage to flush it's buffer it will be safe for the client to close the file (redirected stdout)? In case anything is missing in the file, it wasn't properly output/flushed by the server?
– Bugsy
Nov 14 '18 at 15:05
Probably. Once the server has the file descriptor for the client’s standard output open, it shouldn’t matter if the client closes its output. And if only the server is writing to the client’s standard output, then any missing information is the server’s problem. (I still think this is an appallingly awful design. I’m explaining what I believe will happen, but I still think that the design is wrong — utterly the wrong way to approach the problem.)
– Jonathan Leffler
Nov 14 '18 at 15:13
|
show 1 more comment
The server can only do the trick if the client runs on the same machine. It’s a moderately putrid trick. The client should flush its standard output before sending a request to the server. If the server is using file stream I/O, then it needs to flush its redirected output before returning control to the client.
– Jonathan Leffler
Nov 14 '18 at 13:47
Yes they are obviously running on the same machine as I make use of the proc fs. I agree that it may not be a perfect solution, but due to the prerequisites of the project the server had to handle the output. I guess that the client has to flush in order to synchronize output with the server, but in this case the client will be completely silent so I guess it means that it not applicable? Based on what you say, I assume that output from the server will go straight to stdout or a file depending on what's defined in the client, without passing any buffer in the client(?).
– Bugsy
Nov 14 '18 at 14:44
The client code will never see any of the output from the server. It will go direct to the file or device that the client is using as standard output.
– Jonathan Leffler
Nov 14 '18 at 14:46
So I guess that as long as the server manage to flush it's buffer it will be safe for the client to close the file (redirected stdout)? In case anything is missing in the file, it wasn't properly output/flushed by the server?
– Bugsy
Nov 14 '18 at 15:05
Probably. Once the server has the file descriptor for the client’s standard output open, it shouldn’t matter if the client closes its output. And if only the server is writing to the client’s standard output, then any missing information is the server’s problem. (I still think this is an appallingly awful design. I’m explaining what I believe will happen, but I still think that the design is wrong — utterly the wrong way to approach the problem.)
– Jonathan Leffler
Nov 14 '18 at 15:13
The server can only do the trick if the client runs on the same machine. It’s a moderately putrid trick. The client should flush its standard output before sending a request to the server. If the server is using file stream I/O, then it needs to flush its redirected output before returning control to the client.
– Jonathan Leffler
Nov 14 '18 at 13:47
The server can only do the trick if the client runs on the same machine. It’s a moderately putrid trick. The client should flush its standard output before sending a request to the server. If the server is using file stream I/O, then it needs to flush its redirected output before returning control to the client.
– Jonathan Leffler
Nov 14 '18 at 13:47
Yes they are obviously running on the same machine as I make use of the proc fs. I agree that it may not be a perfect solution, but due to the prerequisites of the project the server had to handle the output. I guess that the client has to flush in order to synchronize output with the server, but in this case the client will be completely silent so I guess it means that it not applicable? Based on what you say, I assume that output from the server will go straight to stdout or a file depending on what's defined in the client, without passing any buffer in the client(?).
– Bugsy
Nov 14 '18 at 14:44
Yes they are obviously running on the same machine as I make use of the proc fs. I agree that it may not be a perfect solution, but due to the prerequisites of the project the server had to handle the output. I guess that the client has to flush in order to synchronize output with the server, but in this case the client will be completely silent so I guess it means that it not applicable? Based on what you say, I assume that output from the server will go straight to stdout or a file depending on what's defined in the client, without passing any buffer in the client(?).
– Bugsy
Nov 14 '18 at 14:44
The client code will never see any of the output from the server. It will go direct to the file or device that the client is using as standard output.
– Jonathan Leffler
Nov 14 '18 at 14:46
The client code will never see any of the output from the server. It will go direct to the file or device that the client is using as standard output.
– Jonathan Leffler
Nov 14 '18 at 14:46
So I guess that as long as the server manage to flush it's buffer it will be safe for the client to close the file (redirected stdout)? In case anything is missing in the file, it wasn't properly output/flushed by the server?
– Bugsy
Nov 14 '18 at 15:05
So I guess that as long as the server manage to flush it's buffer it will be safe for the client to close the file (redirected stdout)? In case anything is missing in the file, it wasn't properly output/flushed by the server?
– Bugsy
Nov 14 '18 at 15:05
Probably. Once the server has the file descriptor for the client’s standard output open, it shouldn’t matter if the client closes its output. And if only the server is writing to the client’s standard output, then any missing information is the server’s problem. (I still think this is an appallingly awful design. I’m explaining what I believe will happen, but I still think that the design is wrong — utterly the wrong way to approach the problem.)
– Jonathan Leffler
Nov 14 '18 at 15:13
Probably. Once the server has the file descriptor for the client’s standard output open, it shouldn’t matter if the client closes its output. And if only the server is writing to the client’s standard output, then any missing information is the server’s problem. (I still think this is an appallingly awful design. I’m explaining what I believe will happen, but I still think that the design is wrong — utterly the wrong way to approach the problem.)
– Jonathan Leffler
Nov 14 '18 at 15:13
|
show 1 more comment
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53300787%2fwhich-buffers-to-flush%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53300787%2fwhich-buffers-to-flush%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The server can only do the trick if the client runs on the same machine. It’s a moderately putrid trick. The client should flush its standard output before sending a request to the server. If the server is using file stream I/O, then it needs to flush its redirected output before returning control to the client.
– Jonathan Leffler
Nov 14 '18 at 13:47
Yes they are obviously running on the same machine as I make use of the proc fs. I agree that it may not be a perfect solution, but due to the prerequisites of the project the server had to handle the output. I guess that the client has to flush in order to synchronize output with the server, but in this case the client will be completely silent so I guess it means that it not applicable? Based on what you say, I assume that output from the server will go straight to stdout or a file depending on what's defined in the client, without passing any buffer in the client(?).
– Bugsy
Nov 14 '18 at 14:44
The client code will never see any of the output from the server. It will go direct to the file or device that the client is using as standard output.
– Jonathan Leffler
Nov 14 '18 at 14:46
So I guess that as long as the server manage to flush it's buffer it will be safe for the client to close the file (redirected stdout)? In case anything is missing in the file, it wasn't properly output/flushed by the server?
– Bugsy
Nov 14 '18 at 15:05
Probably. Once the server has the file descriptor for the client’s standard output open, it shouldn’t matter if the client closes its output. And if only the server is writing to the client’s standard output, then any missing information is the server’s problem. (I still think this is an appallingly awful design. I’m explaining what I believe will happen, but I still think that the design is wrong — utterly the wrong way to approach the problem.)
– Jonathan Leffler
Nov 14 '18 at 15:13