Why is the process state in task_struct stored as type 'long'?

Question

In the Linux kernel tree, the file /include/linux/sched.h contains task_struct which, among other data, defines a variable volatile long state.

According to this page, the number stored in state represents one of five states:

#define TASK_RUNNING            0
#define TASK_INTERRUPTIBLE      1
#define TASK_UNINTERRUPTIBLE    2
#define TASK_ZOMBIE             4
#define TASK_STOPPED            8

My question is as follows:

Why is such a large datatype used to store the state? Wouldn't a single byte be perfectly sufficient to store the states above? Surely, long wasn't chosen in anticipation of thousands/millions of possible states?

I'm aware that the definition of long will vary across the different architectures, but I thought char would have sufficed.

Answer 1

You can easily see these values are power-of-2. This is the standard way to handle /flags/. You can logically OR ('|') them to create cobined states. And then you can easily test them with AND ('&').

long on a 32-bit platform will only be 32-bit.

So, with long on a 32-bit platform you only have 32 distinct flags, as opposed to millions.

Finally, I strongly suggest inspecting actual sources and preferably from this decade, see:

#define TASK_RUNNING            0
#define TASK_INTERRUPTIBLE      1
#define TASK_UNINTERRUPTIBLE    2
#define __TASK_STOPPED          4
#define __TASK_TRACED           8
/* in tsk->exit_state */
#define EXIT_DEAD               16
#define EXIT_ZOMBIE             32
#define EXIT_TRACE              (EXIT_ZOMBIE | EXIT_DEAD)
/* in tsk->state again */
#define TASK_DEAD               64
#define TASK_WAKEKILL           128
#define TASK_WAKING             256
#define TASK_PARKED             512
#define TASK_NOLOAD             1024
#define TASK_STATE_MAX          2048

And flag usage below, e.g.

#define TASK_KILLABLE           (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)

So, the question is why would this be long instead of an int. That I don't know, but it is unlikely there is any particularly good reason.