So Many Questions . . .

[TheSpook]

Greetings, folks! I have a compendium of questions for the forum. All comments are welcome and appreciated!


1) In C, why would I want to use fork() over threads (or vice versa)? Forking makes more sense before a call to exec(), but other than that what are the advantages/disadvantages
of fork/threads?


2) From the terminal, cat'ing /proc/cpuinfo yields (among other information):

		address sizes   : 36 bits physical, 48 bits virtual

Is there any rhyme or reason to choose 36 bits for the physical addresses? This laptop only has 2 gigs of RAM, so the (more understandable) 32 bit choice would've worked fine.
Specs for the laptop: Vostro 1500, Core 2 Duo, 2 gigs of RAM, running Ubuntu 7.04 64-bit.


3) Is there a time when a zombie child or lost process or something gets so "lost" that I wouldn't be able to kill -9 it? Like . . . somehow the jobs list doesn't include the process anymore or some such?


4) In Java, is there an easy way to find the L1/L2 cache sizes of a processor? I can think of an empirical way -- write some code that needs to load large chunks of data from memory, see how large you could make the chunks before the cache couldn't handle an entire chunk at once, thus everything would slow down a ton.


5) Regarding Sudoku -- what determines how "hard" a board is? I was thinking that you could represent that Sudoku board as a graph coloring problem -- throw edges between each node in each 3x3 box, then each node on the same vertical / horizontal line, and finally try to 9-color the whole thing. From there, I guess you could just remove colors in groups in a way that would somehow confound the final player. How do I determine if the board is "hard" or "easy" after removing some number / arrangement of colors? (I ask because I'd like to just hack together a quick Sudoku board creator for a webpage)



That is about all for now. Sorry for the long post, thanks for reading, and preemptive thanks for responding!

 

[carden]

1) In C, why would I want to use fork() over threads (or vice versa)? Forking makes more sense before a call to exec(), but other than that what are the advantages/disadvantages
of fork/threads?

When would you choose it? I dont know, but two of the most common uses for forking is to detach a process from a terminal (like in creating a daemon) and second, if you application spawns a process of a different type. fork -> child becomes a different program.

2) From the terminal, cat'ing /proc/cpuinfo yields (among other information):

		address sizes   : 36 bits physical, 48 bits virtual

Is there any rhyme or reason to choose 36 bits for the physical addresses? This laptop only has 2 gigs of RAM, so the (more understandable) 32 bit choice would've worked fine.
Specs for the laptop: Vostro 1500, Core 2 Duo, 2 gigs of RAM, running Ubuntu 7.04 64-bit.

The reason for this is because your processor is a 64 bit proc that is capable of addressing more then a 32 bit address space. 32 bit processors tend to not have this information in /proc

3) Is there a time when a zombie child or lost process or something gets so "lost" that I wouldn't be able to kill -9 it? Like . . . somehow the jobs list doesn't include the process anymore or some such?

Yes.

4) In Java, is there an easy way to find the L1/L2 cache sizes of a processor? I can think of an empirical way -- write some code that needs to load large chunks of data from memory, see how large you could make the chunks before the cache couldn't handle an entire chunk at once, thus everything would slow down a ton.

no idea.

5) Regarding Sudoku

Thats about ad far as I got in that question before I lost interest.

 

[TheSpook]

Regarding your "yes" to the zombie child getting lost -- can you please give some more information regarding when this would occur? How would the process become so untraceable / unkillable?

Also, regarding your response to the 36-bit addresses -- I was curious more as to why 36 bits are being used. What's so special about the ability to address 16 GB of memory?

 

[carden]

There are many ways in which a process becomes zombified, and probably several in which a kill -9 will not tear them down. How and why I cant really say but I have had processes turn zombie from an SSH session, then when I disconnected the session not be able to kill it. maybe because the controling terminal is no longer active, dont know.

on the processor, I dont know so I will go with bigger is better! that sounds like a reasonable explanation for anything.

 

[generelz]

Greetings, folks! I have a compendium of questions for the forum. All comments are welcome and appreciated!

1) In C, why would I want to use fork() over threads (or vice versa)? Forking makes more sense before a call to exec(), but other than that what are the advantages/disadvantages
of fork/threads?

fork() is a system call which allows a programmer to spawn an entirely new process, based on the POSIX standard.

Threads are a general computing concept which are implemented in a variety of ways, depending on the language / operating system. So, really, comparing them doesn't make much sense.

Maybe you're talking about using fork() versus using POSIX threads (pthreads), since that would make more sense? fork() on most operating systems creates an entirely new process that is a copy of the parent process but does not share the same memory space (heap) (actually, it will share the same memory space until the child process does a write operation, but that is a sticky implementation detail). In general, threads share the same memory space (heap). The funny thing is on linux, pthreads are IMPLEMENTED as separate processes.

Just remember - there is a difference in many things in the programming world when it comes to implementation versus theory. Threads are a theory/API. fork() is an "implementation" or way of accomplishing many of the ideas of multi-threaded/multi-process computing.

At least this is how I was taught/understand it...but to be fair I can't say I've used either one so take my explanation with a healthy dose of salt.

2) From the terminal, cat'ing /proc/cpuinfo yields (among other information):

		address sizes   : 36 bits physical, 48 bits virtual

Is there any rhyme or reason to choose 36 bits for the physical addresses? This laptop only has 2 gigs of RAM, so the (more understandable) 32 bit choice would've worked fine.
Specs for the laptop: Vostro 1500, Core 2 Duo, 2 gigs of RAM, running Ubuntu 7.04 64-bit.

http://en.wikipedia.org/wiki/Physical_Address_Extension

3) Is there a time when a zombie child or lost process or something gets so "lost" that I wouldn't be able to kill -9 it? Like . . . somehow the jobs list doesn't include the process anymore or some such?

Can't say I know the answer to this, sorry.

4) In Java, is there an easy way to find the L1/L2 cache sizes of a processor? I can think of an empirical way -- write some code that needs to load large chunks of data from memory, see how large you could make the chunks before the cache couldn't handle an entire chunk at once, thus everything would slow down a ton.

You would probably have to do this by writing some "native" code in C/C++ and using JNI to call that native code. AFAIK there is no facility or API for retrieving hardware specific information via the JVM (one of the drawbacks of running in a virtual machine environment is that it abstracts away all the hardware).

 

[CefiroZ]

5) Regarding Sudoku -- what determines how "hard" a board is? I was thinking that you could represent that Sudoku board as a graph coloring problem -- throw edges between each node in each 3x3 box, then each node on the same vertical / horizontal line, and finally try to 9-color the whole thing. From there, I guess you could just remove colors in groups in a way that would somehow confound the final player. How do I determine if the board is "hard" or "easy" after removing some number / arrangement of colors? (I ask because I'd like to just hack together a quick Sudoku board creator for a webpage)

I'm not a Sudoku player but I had to write a solver using Scheme for an AI class a few years ago. There are no set rules on how difficulty is defined as far as I know; it depends on whoever wrote the puzzle/book/etc. Typically there are 3, 4, or 5 level ratings, with 3 being the most common: easy, medium, hard. The other one or two ratings are above hard are just "deeper down the rabbit hole" sorts of things. The way I always thought about it was easy can be solved by simple scanning/elimination, medium will require more passes and may need a little bookkeeping, and hard was when deeper analysis or guesses and backtracking were required.