OSDev.org

How about doing it the other way. You have pointers as PIDs but the kernel validates the pointer for every system call. Basically, you can have a hash lookup of the pointer and if the pointer doesn't exist as a key, the pointer is invalid.

The problem with pointers as pids is that pointers get re-used too quickly. 2 processes may be waiting for a pointer pid. The first will perhaps get the right one, the second may get a re-used pointer. This is especially bad in kernels where data structures are recycled often for efficiency. Pids on the other hand are not re-used until every pid has been used.

Also, I'm not sure that there is a speed benefit. As you said, hashing and validation will be required on every system call. And there are some tricks to speed up bitmap search so that linear search in bitmaps is minimised.

gerryg400 wrote:

How about doing it the other way. You have pointers as PIDs but the kernel validates the pointer for every system call. Basically, you can have a hash lookup of the pointer and if the pointer doesn't exist as a key, the pointer is invalid.

The problem with pointers as pids is that pointers get re-used too quickly. 2 processes may be waiting for a pointer pid. The first will perhaps get the right one, the second may get a re-used pointer. This is especially bad in kernels where data structures are recycled often for efficiency. Pids on the other hand are not re-used until every pid has been used.

Also, I'm not sure that there is a speed benefit. As you said, hashing and validation will be required on every system call. And there are some tricks to speed up bitmap search so that linear search in bitmaps is minimised.

I was thinking about this problem and you could basically mangle the pointer. You can get the time stamp at the thread creation, store the timestamp. Using the time stamp you could use some obscure algorithm that encrypts the pointer. Then you definitely have a pretty unique threadID/pointer.

Ok, then it's not pointers anymore but more PIDs again but you have removed the step where you need to allocate a PID. At system calls you use the mangled pointer/PID in the hash lookup, then you decrypt it using the time stamp in order to get the proper pointer.

Oh good god.

If you have a hash table... why not just key off the PID and store the actual address of the process structure in it?

You seriously sound like the complicator

Owen wrote:Oh good god.

If you have a hash table... why not just key off the PID and store the actual address of the process structure in it?

You seriously sound like the complicator

I think we're talking about the same thing actually, since that is what I suggested.

OSwhatever, as you can see, once all problems are addressed the solutions converge. As I said there are very efficient ways to remove the need for long linear searches through the pid bitmap. For me the deciding factor in using the 'small integer pid' was the fact that 'small integer pids' are more readable. During debugging my O/S I became used to pid=1=memory_manager, pid=2=fs_manager, pid=3=console_manager etc.

And later on when, god willing, real users use your system, kill -9 1328 is nicer than kill -9 0xffffffffcf023b40