[LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Caspar Zhang]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]


when executing with `$BIN/runltp` command, getrusage03 puts out
duplicated information due to buffered stdout. Using fflush(stdout) to
solve this issue.

Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
---
 testcases/kernel/syscalls/getrusage/getrusage03.c  |    7 +++++++
 .../kernel/syscalls/getrusage/getrusage03_child.c  |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-syscalls-getrusage03-flush-stdout-to-avoid-duplicate.patch --]
[-- Type: text/x-patch; name="0001-syscalls-getrusage03-flush-stdout-to-avoid-duplicate.patch", Size: 2544 bytes --]

diff --git a/testcases/kernel/syscalls/getrusage/getrusage03.c b/testcases/kernel/syscalls/getrusage/getrusage03.c
index 3ec5284..df25ff0 100644
--- a/testcases/kernel/syscalls/getrusage/getrusage03.c
+++ b/testcases/kernel/syscalls/getrusage/getrusage03.c
@@ -104,6 +104,7 @@ static void inherit_fork(void)
 	SAFE_GETRUSAGE(cleanup, RUSAGE_SELF, &ru);
 	tst_resm(TINFO, "initial.self = %ld", ru.ru_maxrss);
 
+	fflush(stdout);
 	switch (pid = fork()) {
 	case -1:
 		tst_brkm(TBROK|TERRNO, cleanup, "fork #1");
@@ -135,6 +136,7 @@ static void inherit_fork2(void)
 	else
 		tst_resm(TFAIL, "initial.children !~= 100MB");
 
+	fflush(stdout);
 	switch (pid = fork()) {
 	case -1:
 		tst_brkm(TBROK|TERRNO, cleanup, "fork #2");
@@ -161,6 +163,7 @@ static void fork_malloc(void)
 	SAFE_GETRUSAGE(cleanup, RUSAGE_SELF, &ru);
 	tst_resm(TINFO, "initial.self = %ld", ru.ru_maxrss);
 
+	fflush(stdout);
 	switch (pid = fork()) {
 	case -1:
 		tst_brkm(TBROK|TERRNO, cleanup, "fork #3");
@@ -190,6 +193,7 @@ static void grandchild_maxrss(void)
 	SAFE_GETRUSAGE(cleanup, RUSAGE_CHILDREN, &ru);
 	tst_resm(TINFO, "initial.children = %ld", ru.ru_maxrss);
 
+	fflush(stdout);
 	switch (pid = fork()) {
 	case -1:
 		tst_brkm(TBROK|TERRNO, cleanup, "fork #4");
@@ -225,6 +229,7 @@ static void zombie(void)
 	tst_resm(TINFO, "initial.children = %ld", ru.ru_maxrss);
 	maxrss_init = ru.ru_maxrss;
 
+	fflush(stdout);
 	switch (pid = fork()) {
 	case -1:
 		tst_brkm(TBROK, cleanup, "fork #5");
@@ -269,6 +274,7 @@ static void sig_ign(void)
 	signal(SIGCHLD, SIG_IGN);
 	maxrss_init = ru.ru_maxrss;
 
+	fflush(stdout);
 	switch (pid = fork()) {
 	case -1:
 		tst_brkm(TBROK, cleanup, "fork #6");
@@ -306,6 +312,7 @@ static void exec_without_fork(void)
 	maxrss_child = ru.ru_maxrss;
 	tst_resm(TINFO, "initial.self = %ld, initial.children = %ld",
 		    maxrss_self, maxrss_child);
+	fflush(stdout);
 
 	sprintf(str_maxrss_self, "%ld", maxrss_self);
 	sprintf(str_maxrss_child, "%ld", maxrss_child);
diff --git a/testcases/kernel/syscalls/getrusage/getrusage03_child.c b/testcases/kernel/syscalls/getrusage/getrusage03_child.c
index a9c1d38..f5d2850 100644
--- a/testcases/kernel/syscalls/getrusage/getrusage03_child.c
+++ b/testcases/kernel/syscalls/getrusage/getrusage03_child.c
@@ -87,6 +87,7 @@ int main(int argc, char *argv[])
 			grand_consume_nr = get_long(grand_consume_str);
 			tst_resm(TINFO, "grandchild allocate %ldMB",
 				    grand_consume_nr);
+			fflush(stdout);
 			switch (pid = fork()) {
 			case -1:
 				tst_brkm(TBROK, cleanup, "fork");

[-- Attachment #3: Type: text/plain, Size: 355 bytes --]

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Caspar Zhang]

On 2012年01月10日 11:38, Caspar Zhang wrote:
> 
> when executing with `$BIN/runltp` command, getrusage03 puts out
> duplicated information due to buffered stdout. Using fflush(stdout) to
> solve this issue.
> 
> Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
> ---
>  testcases/kernel/syscalls/getrusage/getrusage03.c  |    7 +++++++
>  .../kernel/syscalls/getrusage/getrusage03_child.c  |    1 +
>  2 files changed, 8 insertions(+), 0 deletions(-)
> 

Not sure if we have any better solution to avoid such buffered I/O issue.

Caspar

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Wanlong Gao]

On 01/10/2012 11:40 AM, Caspar Zhang wrote:

> On 2012年01月10日 11:38, Caspar Zhang wrote:
>>
>> when executing with `$BIN/runltp` command, getrusage03 puts out
>> duplicated information due to buffered stdout. Using fflush(stdout) to
>> solve this issue.
>>
>> Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
>> ---
>>  testcases/kernel/syscalls/getrusage/getrusage03.c  |    7 +++++++
>>  .../kernel/syscalls/getrusage/getrusage03_child.c  |    1 +
>>  2 files changed, 8 insertions(+), 0 deletions(-)
>>
> 
> Not sure if we have any better solution to avoid such buffered I/O issue.


I think it's OK.

Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>

Thanks
-Wanlong Gao

> 
> Caspar
> 



------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Cyril Hrubis]

Hi!
> > when executing with `$BIN/runltp` command, getrusage03 puts out
> > duplicated information due to buffered stdout. Using fflush(stdout) to
> > solve this issue.
> > 
> > Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
> > ---
> >  testcases/kernel/syscalls/getrusage/getrusage03.c  |    7 +++++++
> >  .../kernel/syscalls/getrusage/getrusage03_child.c  |    1 +
> >  2 files changed, 8 insertions(+), 0 deletions(-)
> > 
> 
> Not sure if we have any better solution to avoid such buffered I/O issue.
> 

That seems to be a hack and not only because you don't know to which
file the tst_resm() is printing.

What is exactly the problem here?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Jan Stancek]

----- Original Message -----
> From: "Caspar Zhang" <caspar@casparzhang.com>
> To: "LTP List" <ltp-list@lists.sourceforge.net>
> Sent: Tuesday, January 10, 2012 4:40:02 AM
> Subject: Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output
> 
> On 2012年01月10日 11:38, Caspar Zhang wrote:
> > 
> > when executing with `$BIN/runltp` command, getrusage03 puts out
> > duplicated information due to buffered stdout. Using fflush(stdout)
> > to
> > solve this issue.
> > 
> > Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
> > ---
> >  testcases/kernel/syscalls/getrusage/getrusage03.c  |    7 +++++++
> >  .../kernel/syscalls/getrusage/getrusage03_child.c  |    1 +
> >  2 files changed, 8 insertions(+), 0 deletions(-)
> > 
> 
> Not sure if we have any better solution to avoid such buffered I/O
> issue.

How about "setvbuf(stdout, NULL, _IOLBF, 0);"?

Regards,
Jan

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Cyril Hrubis]

Hi!
> > > when executing with `$BIN/runltp` command, getrusage03 puts out
> > > duplicated information due to buffered stdout. Using fflush(stdout)
> > > to
> > > solve this issue.
> > > 
> > > Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
> > > ---
> > >  testcases/kernel/syscalls/getrusage/getrusage03.c  |    7 +++++++
> > >  .../kernel/syscalls/getrusage/getrusage03_child.c  |    1 +
> > >  2 files changed, 8 insertions(+), 0 deletions(-)
> > > 
> > 
> > Not sure if we have any better solution to avoid such buffered I/O
> > issue.
> 
> How about "setvbuf(stdout, NULL, _IOLBF, 0);"?
> 

I still think that this is a workaround for something that should be
either avoided or fixed on different level.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Cyril Hrubis]

Hi!
> > I still think that this is a workaround for something that should be
> > either avoided or fixed on different level.
> 
> I'm not sure we can avoid it (stdout is buffered by default),
> but I agree that we can probably do better than fixing it per-test.
> 
> Here's a smaller reproducer:
> 
> cat > a.c <<EOF
> #include <stdio.h>
> int main()
> {
>     printf("hello world\n");
>     fork();fork();
>     return 0;
> }
> EOF
> 
> gcc a.c
> ./a.out | cat
> hello world
> hello world
> hello world
> hello world
> 

I see, each of the forked processes still have the "hello world\n" in
the buffer which is printed from each of them after respective buffer is
flushed.

There are two ways to fix this, either create tst_fork() that flushes
the buffers before forking. This may be problematic as there is a need
for replacing fork() with tst_fork() in several testcases.

Or we could flush the output after each test message is printed with
tst_resm(). That is IMHO ideal solution. The only drawback is that this
may interfere with timings in some testcases (but testcases that expects
exacts timings are usually broken anyway).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Cyril Hrubis]

Hi!
> > There are two ways to fix this, either create tst_fork() that flushes
> > the buffers before forking. This may be problematic as there is a need
> > for replacing fork() with tst_fork() in several testcases.
> 
> if we wanted to be lazy, it would be easy to catch.  in our test.h:
> 	#define fork() tst_fork()
> then in the single file defining tst_fork(), we do:
> 	#undef fork
> or forcing it via:
> 	#define fork() __use_tst_fork()
> 
> but we already have to track in the ltp tests where fork() is used since this 
> breaks NOMMU builds (i.e. UCLINUX), so it's not like we don't already have 
> this issue.

I don't like idea of defining fork to tst_fork that's exactly the
magic that may take hours to figure out.

Forcing it, in this case, is probably good idea.

> > Or we could flush the output after each test message is printed with
> > tst_resm(). That is IMHO ideal solution. The only drawback is that this
> > may interfere with timings in some testcases (but testcases that expects
> > exacts timings are usually broken anyway).
> 
> i agree those tests are broken if the flushing causes issues due to a slow 
> down.  however, slow downs in general are not a good thing, especially when 
> these are only needed for apps that fork.  i'd like to think we could do 
> better.

Still I'm slighlty for this one. In general case, flushing the buffer
often is bad, but considering relatively rare usage of tst_resm() the
slowdowns woudn't be most likely measurable (and it's flushed after
every '\n' when you run the test in the terminal anyway).

Side effects of this are generally possitive too, the messages from
parent and child, or several threads wouldn't be so badly intermixed in
the output.

> a third option would be to use pthread_atfork().  no tracking needed in random 
> tests since we can call this in the common ltp init func.  downside is we'd 
> have to use -pthread in our CFLAGS.
> 
> $ cat test.c
> #include <pthread.h>
> #include <stdio.h>
> void prep(void) { fflush(stdout); }
> int main(){
> 	printf("foo\n");
> 	pthread_atfork(prep, NULL, NULL);
> 	fork();fork();fork();fork();
> 	return 0;
> }
> $ gcc -pthread test.c && ./a.out | cat
> foo

The -phtread changes several definitions in glibc headers so adding it
globally for all the tests seems wrong.

> a fourth option would be to include <bits/libc-lock.h> and use 
> __libc_atfork(), but this would be glibc specific :(.

Yeah, another no go option.

> a fifth option would be to use libdl, override the fork() symbol with our own 
> and then dlsym() to the direct fork() symbol.  but like the pthread solution, 
> this would require linking all apps with -ldl, and it would only work on ELF 
> based systems (so it would break embedded things like FLAT on NOMMU).

Not to mention, this is starting to fall into 'overcomplicated solutions'
category. I would like to keep things as simple as possible.

> so all in all, i think the tst_fork() is the best way to go.  if tracking 
> really gets out of hand, since the compile+link steps are in common .mk code, 
> it'd be easy to add a post-link test that looks to see if the ELF uses fork() 
> without calling tst_fork() ...

As I said above, I'm slightly for flushing buffers in the library code,
but generally either of these two would do.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Cyril Hrubis]

Hi!
> > > if we wanted to be lazy, it would be easy to catch.  in our test.h:
> > > 	#define fork() tst_fork()
> > > 
> > > then in the single file defining tst_fork(), we do:
> > > 	#undef fork
> > > 
> > > or forcing it via:
> > > 	#define fork() __use_tst_fork()
> > > 
> > > but we already have to track in the ltp tests where fork() is used since
> > > this breaks NOMMU builds (i.e. UCLINUX), so it's not like we don't
> > > already have this issue.
> > 
> > I don't like idea of defining fork to tst_fork that's exactly the
> > magic that may take hours to figure out.
> > 
> > Forcing it, in this case, is probably good idea.
> 
> tst_fork() would be the route i'd prefer to go, and i think since we already 
> take pains in this area to support NOMMU, it isn't an additional burden.

Hmm, maybe we could get rid of the FORK_OR_VFORK macro and use
tst_fork() to cover both flusing and no NOMMU target. That actually
looks like good way to go. So let's fix this that way.

> > > > Or we could flush the output after each test message is printed with
> > > > tst_resm(). That is IMHO ideal solution. The only drawback is that this
> > > > may interfere with timings in some testcases (but testcases that
> > > > expects exacts timings are usually broken anyway).
> > > 
> > > i agree those tests are broken if the flushing causes issues due to a
> > > slow down.  however, slow downs in general are not a good thing,
> > > especially when these are only needed for apps that fork.  i'd like to
> > > think we could do better.
> > 
> > Still I'm slighlty for this one. In general case, flushing the buffer
> > often is bad, but considering relatively rare usage of tst_resm() the
> > slowdowns woudn't be most likely measurable (and it's flushed after
> > every '\n' when you run the test in the terminal anyway).
> 
> i just recall seeing some verbose tests in the past, and often times people 
> are writing to logs.  maybe in that case, there would be a bit of test time 
> slow down, and if there's one thing i learned from doing release engineering 
> at my last job, testing causes the longest delays :(.

I remeber some too, and also remember silecing some of them as the output
was no more than forgotten debug output and was interfering with the
testing as well (the realtime testcases that were printing someting in
the ineer loops, etc...).

And yes, careful testing takes time, a lot of it.

> > Side effects of this are generally possitive too, the messages from
> > parent and child, or several threads wouldn't be so badly intermixed in
> > the output.
> 
> does that happen ?  POSIX guarantees printf() and friends to be multithreaded 
> safe, so no lines would be inter-mingled, and they're sharing the same FILE*, 
> so i wouldn't see adding a fflush() making a difference.

Looked at the code and there is yet another reason for this, the
printing is done with more than one printf(), so rarely the lines could
get intermixed. I'll fix that.

> > > a fifth option would be to use libdl, override the fork() symbol with our
> > > own and then dlsym() to the direct fork() symbol.  but like the pthread
> > > solution, this would require linking all apps with -ldl, and it would
> > > only work on ELF based systems (so it would break embedded things like
> > > FLAT on NOMMU).
> > 
> > Not to mention, this is starting to fall into 'overcomplicated solutions'
> > category. I would like to keep things as simple as possible.
> 
> overcomplicated ?  absolutely.  a lot of fun and interesting to implement ?  
> absolutely ;).

Totally understand that, however I like to keep such fun out of the
projects I need to maintain ;).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Cyril Hrubis]

Hi!
> > > > I don't like idea of defining fork to tst_fork that's exactly the
> > > > magic that may take hours to figure out.
> > > > 
> > > > Forcing it, in this case, is probably good idea.
> > > 
> > > tst_fork() would be the route i'd prefer to go, and i think since we
> > > already take pains in this area to support NOMMU, it isn't an additional
> > > burden.
> > 
> > Hmm, maybe we could get rid of the FORK_OR_VFORK macro and use
> > tst_fork() to cover both flusing and no NOMMU target. That actually
> > looks like good way to go. So let's fix this that way.
> 
> my concern with this is that by having "vfork" in the name people know they 
> need to be aware of the vfork semantics.  there are places where vfork/fork 
> are interchangeable (and hence we use FORK_OR_VFORK).  but there are places 
> where they are not, and so we end up doing one of two things:
> 	- rewrite it to use FORK_OR_VFORK and self_exec
> 	- disable the test altogether

Ah, I see, so vfork() doesn't do the copy on write thing with program
memory. Hmm and it makes sense to use vfork() on non-mmu system as you
can't implement copy on write approach there. I think I'm starting to
uderstand this works.

> so i don't think we want to blindly have everyone get "fork or vfork" 
> semantics.  the current methodology allows for mmu devs to contribute tests 
> without worrying about these issues.  then the non-mmu peeps notice the new 
> tests (because they get build failures due to fork() not being defined), and 
> they get to go in and review each test to see what's needed.

Okay, that makes sense.

> certainly the existing FORK_OR_VFORK/self_exec api could do with a minor 
> cleanup and unification.  i think the reason we have it do vfork+self-exec on 
> nommu but fork on mmu is to keep things simpler for the main dev base, but i 
> wouldn't be opposed to just always having tsts do vfork+self-exec so as to 
> reduce the #ifdef ugliness in tests.

I will meditate about that (I do not fully understand how exactly is
maybe_run_child() and self_exec() working yet).

> > > does that happen ?  POSIX guarantees printf() and friends to be
> > > multithreaded safe, so no lines would be inter-mingled, and they're
> > > sharing the same FILE*, so i wouldn't see adding a fflush() making a
> > > difference.
> > 
> > Looked at the code and there is yet another reason for this, the
> > printing is done with more than one printf(), so rarely the lines could
> > get intermixed. I'll fix that.
> 
> that would be good ... i think even if we had flushing, the multi-thread issue 
> would still be there because of what you've found.

I've just commited fix for this one. But there are some more problems,
global buffer for composing warning messages for example, which is not
likely to cause trouble as you would need to use the tst interface
incorrectly from more threads at once, but still that could happen.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Cyril Hrubis]

Hi!
> > > certainly the existing FORK_OR_VFORK/self_exec api could do with a minor
> > > cleanup and unification.  i think the reason we have it do
> > > vfork+self-exec on nommu but fork on mmu is to keep things simpler for
> > > the main dev base, but i wouldn't be opposed to just always having tsts
> > > do vfork+self-exec so as to reduce the #ifdef ugliness in tests.
> > 
> > I will meditate about that (I do not fully understand how exactly is
> > maybe_run_child() and self_exec() working yet).
> 
> many tests want to fork a child to run some code.  and the parent watches that 
> in parallel.  on no-mmu, we can't do that (vfork blocks the parent until the 
> child exits or execs).  so instead, we vfork, then exec the test with special 
> params.  the test code looks at its args to see if it is being executed like 
> normal, or if it needs to execute in "child mode".  once it does, the test 
> continues on like it would normally.

Ah, right, I expected something like that.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] syscalls/getrusage03: flush stdout to avoid duplicated output

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 324 bytes --]

On Monday 09 January 2012 22:38:12 Caspar Zhang wrote:
> when executing with `$BIN/runltp` command, getrusage03 puts out
> duplicated information due to buffered stdout. Using fflush(stdout) to
> solve this issue.

NAK to this version.  it's a general issue with LTP and forking and should be 
solved as such.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 186 bytes --]

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list