Do you think that the standard GHC behavior should be for multithreaded programs to produce garbage on stderr?
C is different because it's not lazy. Usually small lines are printed to stderr; they fit in a single 'write' call and even if there are multiple such calls they usually happen within the same processor timeslice. I think that in the GHC runtime, the default buffering mode for stderr should be line buffering (or perhaps, the same rules as for stdout should apply). I've modified my logging library to pre-evaluate strings with 'seq' and to use locking when writing messages to 'stderr', so it is no longer a problem for me personally; but for new users, for general-purpose use of the compiler, I think changing the stderr buffering mode is the best solution. Regards, Frederik On Wed, Aug 23, 2006 at 10:41:02AM +0100, Simon Marlow wrote: > Frederik Eaton wrote: > >Hey, it looks like the output of two threads is being interleaved one > >character at a time. Is that really the most efficient way to schedule > >threads? Anyway, so I guess I need to set stdout and stderr to be line > >buffered? Perhaps that should be the default setting? ... > > stderr is always unbufferred by default, this is pretty standard (I believe > it's the same in C's > stdio). stdout should be line bufferred if connected to a terminal, or > block-bufferred if connected > to a file. > > Cheers, > Simon > > >---------------------------------------------------------------- > >2006-08-22 22:49:58 4: querying (select cmdid from pfcq_study_cmdid where > >user=2;) > >2006-08-22 22:49:58 4: duration: 0.5 msec > >2006-08-22 22:49:58 4: executing (up2d0a0t6e- 0p8f-c2q2_ s2t2u:d4y9_:c5m8d > >i3d: sueste rc m=d i2d, > > =c ocmmmdaindd+ 1= wrheegries tuesre-rp=a2g;e)- > >vi2e0w0 > >6-20080-62-20 82-22:24 92:25:84 94::5 8 3d:u reaxteicount:i n0g. 3( > >smtsaerct > > t2r0a0n6s-a0c8t-i2o2n )2 > >2:24090:65-80 84-:2 2e x2e2c:u4t9i:n5g8 (3c:o m m idtu)r > >ation: 5.9e-2 msec > >2006-08-22 22:49:58 3: querying (select cmdid from pfcq_study_cmdid where > >user=2;) > >2006-08-22 22:49:58 3: duration: 0.3 msec > >2006-08-22 22:49:58 3: executing (update pfcq_study_cmdid set cmdid = > >cmdid+1 where user=2;) > >---------------------------------------------------------------- > >Frederik > >On Tue, Aug 22, 2006 at 02:43:36PM +0100, Frederik Eaton wrote: > >>I can't repeat it, but I can let you know if it happens again. I'm > >>writing with 'hPutStr', but not directly - rather via some modules in > >>a package I wrote. Kernel is Linux 2.6.16, libc 2.3.6, running Debian. > >> > >>Frederik > >> > >>On Tue, Aug 22, 2006 at 10:14:19AM +0100, Simon Marlow wrote: > >> > >>>Can you repeat it? What API are you using to write the file? On what OS? > >>> > >>>Cheers, > >>> Simon > >>> > >>>Frederik Eaton wrote: > >>> > >>>>Sorry, forgot to say that I was using GHC 6.4.2 the first time, and > >>>>ghc-6.4.3.20060816 this time. > >>>>Frederik > >>>>On Mon, Aug 21, 2006 at 10:45:40PM +0100, Frederik Eaton wrote: > >>>> > >>>>>Hi, > >>>>> > >>>>>I'm seeing some odd data corruption in a log file. Below, the second > >>>>>line should be a SQL query (prefixed by a timestamp). It's turned into > >>>>>garbage, but apparently not just random bytes. I'm using HSQL - that's > >>>>>the only external library, and it uses FFI, so there might be some bad > >>>>>memory management, but I thought I should ask if other people have > >>>>>seen something similar. It's the second time this has happened to me. > >>>>> > >>>>>---------------------------------------------------------------- > >>>>># fillUpQueue > >>>>>8-22010 62-20:83-12:12 62:2 :e3x1e:c2u6t:i nqgu e(rdyeilnegt e( > >>>>>sferloemc tp fccoqu_nstt(u*d)y > >>>>>_fqruoemu ep fwchqe_rset usdqy__uqsueeru e= w2h)e > >>>>>re sq_user = 2) > >>>>>2006-08-21 22:31:27: duration: 843.8 msec > >>>>># addToQueue > >>>>># getNewCards > >>>>># getVT > >>>>>2006-08-21 22:31:27: querying (select max(res_num) from > >>>>>pfcq_study_results where res_user = 2) > >>>>>2006-08-21 22:31:27: duration: 152.6 msec > >>>>>---------------------------------------------------------------- > >>>>> > >>>>>Regards, > >>>>> > >>>>>Frederik > >>>>> > >>>>>-- > >>>>>http://ofb.net/~frederik/ > >>>>> > >>> > >>-- > >>http://ofb.net/~frederik/ > >> > -- http://ofb.net/~frederik/ _______________________________________________ Glasgow-haskell-bugs mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
