| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10
Comments:
<0> by bits, by nibbles, by bytes, by shorts
<1> of course. but he showed nibble-wise reversal.
<2> looks byte-wise to me
<0> byte-wise
<0> but that ***umes that what he showed is what he needed :-)
<0> might have needed simply htonl(), and miunderstood, and showed wrong example
<0> possible
<1> AaronWL: wouldn't byte-wise be 0x12345678 -> 0x78563412?
<2> a hexadecimal digit is 4 bits
<1> argh, that is what he showed.
<0> <+_k> e.g. 0x12345678 -> 0x78563412
<1> gah.
<2> the insanity. yeah i misread it at first too
<0> when people about about reveral, i 1st take is bit reversal
<2> this would have been an excellent opportunity for the gratuitous violation of #c rules by using mirc colors
<0> *as
<0> unlikely anybody needed byte-wise inversion
<0> makes no sense
<0> oh wait
<0> does make sesne
<2> htonl?
<0> aha
<1> bit-wise reversal is useful, but most people don't need it.
<0> bitwise reversion is my fav interview question
<3> hey is there a shell command that blocks until a pid has exited?
<2> Aeon_, what is your favorite interview answer to your favorite question?
<0> Gamb: it's wait
<1> only for your own children though.
<3> oh, is there a commandline version of wait?
<0> AaronWL: table-driven
<1> shells with job control have wait.
<0> Gamb: yes
<3> someday I'll figure out how to get useful info out of the bash manpage :(
<0> in my shell, all commands will end with 'job'. waitjob, killjob, etc
<3> hrm doesn't seem to work for processes backgrounded in shell scripts.
<0> right, nope
<0> process must be beckgrouneded in *same* script
<0> not in *other* scripts
<1> wait can only wait on direct child processes. i.e., it just calls waitpid.
<3> yeah
<1> it could monitor any pid, if you need that try zsh instead.
<0> twkm: what's zsh command for that
<1> wait n
<1> hmm, no, zsh hates it too.
<1> damn, which shell does like it. /me rummages
<0> OT uses zsh
<0> music is harmful for your concentration
<3> not mine.
<1> the usual solution is along the lines of: while kill -0 $pid; do sleep 1; done
<0> makes sense
<0> twkm: want a small shell quiz ?
<1> *shrug*
<1> if you were to ask something i might respond. i would be uninterested in the "score".
<0> how do you make 1/2 second delay in shell
<3> I have a question, then. I need/want to start off oh, I dunno, maybe a 100 sessions of netcat and feed them input. I can start them off fine, but I'd like to wait until they're all finished before calling quit on the main server. Any suggestions for tracking all that pids?
<3> Aeon_, I wrote a nanowait tool :)
<0> Gambit: you mean, in C. I meant, in shell.
<3> Aeon_, well it /works/ in the shell now that I wrote it :D
<0> how long is the source ?
<3> I dunno, five or six lines because I gave it a default if no parameters are supplied?
<3> all it does is call nanowait, nothing very interesting.
<3> so should I just stick each PID in an environment variable PID_1 through PID_n and then wait on them all in turn?
<0> @Gambit-: re your wait-100-process-question
<3> ah - source for which?
<0> i did it once with weird trick and it worked perfectly
<1> Gambit-: you can only use wait with child process pid's. if you can do that just use wait without any argument, which will wait for all of them.
<0> @Gambit-: and without wait
<3> twkm, Ah, cute.
<1> Aeon`: off-hand i'm not overly interested in sub-second waits. how did you do it?
<3> twkm, only problem is that will wait for my server pid as well, though if I call another shell script to start the clients that'll be a seperate fork, right?
<1> Gambit-: right, and in that script do the general wait for all the children it made, then when it returns your server will know that all the children were done too.
<0> twkm: xsleep() { perl -e 'select(undef,undef,undef,'$1')'; }
<0> xsleep 0.5 # sleep 1/2 second
<0> Gambit-: number of processes is variable ?
<3> Aeon_, Yeah, depending on how long I'm looking at waiting (running everything under valgrind is slloooow)
<4> tomorrow on #c, how to kill an ant with a sledgehammer ...
<4> but valgrind is good
<4> except if you get bugs in your non_x86 code i guess
<3> well yeah
<1> Aeon`: not much of a shell solution.
<4> any of you dudes tried to play around with xen ?
<4> i like the idea of virtualization and stuff ... but that label on it's side with a red hatted logo scares me a bit, is it even usable outside fc world ?
<1> yes.
<4> i have given a shot here with qemu and vmware player ... both work almost fine ...
<4> but both have some annoying drawbacks ... and ofcourse a nice bunch of overhead :p
<1> ditto xen.
<0> with >=!G RAM and dualcore, vmware runs fine
<0> *1GB
<4> i have 1 gig of ram here on a turion ... not 2x to
<4> on vmware i dislike the ignorance of the kernel module ... it can't be really controlled
<4> and it has some leaks somewhere, has caused me to crash twice ... otherwise the machine is perfectly stable
<1> in some ways not being able to control the vmware host is a blessing.
<4> not if it runs windows that almost halts all other processes running on the host :p
<0> ignorance of the guest OS is advantage: you can run *any* OS inside
<3> Aeon`, Yeah, I use vmware with 1gb and I'm actually happy enough to develop with it.
<4> Aeon - that is not why meant
<4> i would like to run it sometimes like a 'nice process', meaning windows messes when the cpu has time for it, not when m$ decides it's ok ...
<1> i run windows under vmware, i haven't noticed any tendancy of the host processes to be frozen.
<1> then renice the vmx process.
<1> problem solved.
<4> nope
<4> the kernel module isn't niceable
<4> and that's where it does the "Action"
<4> the vmx process is just a wrapper mostly for a few things only
<4> if windows goes berserk while scanning it's registry or smth like that, the kernel module berserks and is out of control
<4> i wish there would be an alternative mode to run it :)
<4> because i understand that some people really want it to exhaust the cpu at 100% power and as the primary process
<4> but just not me i guess
<0> yeah kernel threads are scheduled differently even if in ps they appear with non-realtime priotiry
<0> thisd is true
<0> i'm not even sure realtime root process can preempt kernel thread
<0> even if priority of KT is lower
<0> it not documented anywhere
<0> i looked into sched.c in kernel and still can't understand where it is
<0> looks like KT are in scheduling clas of themselves
<0> even above realtime
<0> just my guess
<0> the funny thing is, it's not reflected is ps
<0> in ps, KT appears as normal timesharing priotiry
<0> but it preempts realtime processes
<1> oddly i've always had total success controlling badly behaving guests merely by renicing the vmx process.
<0> twkm: maybe it depends on where the guests spends its time, in guest uservevel ,
<0> or in guest kernel
<0> just a gues
<5> I want to see a certain line of C code to see how it's changed in svn
<1> yes, i suppose beating on a virtualized port very hard might be an issue.
<5> in any way..
<5> but revisions back
<5> got it.. n/m
<5> I wrote a program which does an fcntl() flock on a file, it pauses and can be backgrounded so I can lock a particular site resource and do some work, then unlock it.. it uses the same fcntl() calls that the web-ui uses for protection, but this is designed for shell and for shell scripts
<5> however, when my shell script runs it runs the program & then sleeps for 10 seconds HOPING the lock is obtained
<5> what's a good way of testing if the lock was obtained? or is there a way the shell can do the fcntl() lock itself so the lock isn't lost
<5> (if the lock program terminates, it loses the lock; thus, I run it in the background, and once the shell script is done it kills it with its pid)
<1> return a status that indicates if it was successful.
<1> oh, it is backgrounded. you cannot do that.
<6> make your program create a /tmp file once it locked
<1> have your program run what should only be run when the resource is locked.
<1> a'la the util-linux flock(1)
<5> yeah.. didn't want the temp file though.. but I can make one with the pid I guess
<5> twkm, heh.
<5> hmm.. command to run once lock is obtained..
<1> indeed.
<1> flock lockfile script-that-does-stuff
<3> Jaggy_, how about having your program that does the flock then fork and exec what's expected to act while the lock is in action, and that way you can clean up afterwards as well.
<1> of course that means splitting your existing script into "stuff to do unlocked, before and after" and "stuff to do locked" and that second script has no way to prove the lock is effective.
<3> oh, heh, did he just say that? :)
Return to
#c
or
Go to some related
logs:
Mawjood JAR
You Tube Barrett M95
#beginner
pinched butt
#worldcup
#windows
#tcl
#nhl
sata and ide RAID at the same time
gentoo kernel config uri:
|
|