I made a very small program that creates two threads: #include #include #include void *start() { printf("Am a new thread!\n"); printf("%d\n",pthread_self()); } void main() { pthread_t thread_id1; pthread_t thread_id2; pthread_create(&thread_id1,NULL,start,NULL); pthread_create(&thread_id2,NULL,start,NULL); //pthread_join(thread_id,NULL); sleep(30); } When I compile and run the program with: gcc create.c -lpthread ./a.out And I open a new terminal and try to view the threads, this is what I get: ps -efL | grep a.out root 1943 20158 1943 0 1 15:25 pts/4 00:00:00 ./a.out root 1985 1889 1985 0 1 15:25 pts/5 00:00:00 grep --color=auto a.out So why can't I see two thread ids here?

I run [iotop](http://guichaz.free.fr/iotop/) to check on programs that are heavy disk users, in case I need to decrease their priority. Usually this is good enough, but iotop only shows thread ID (TID), and sometimes I want to know process ID (PID) so I can find out more about which process is responsible. Unfortunately, while ps can display TID (a.k.a SPID, LWP), it doesn't have a flag to take a list of TIDs the way it does for a list of PIDs with --pid. The best I can do is list TIDs and then grep the output. For example, if the thread id is 792, I can do $ ps -eLf | grep ' 792 ' which works reasonably well, but is a little inelegant. Is there a better way?

I am working on an embedded Linux system (kernel-5.10.24). There is a multi-threaded process needed to handle a certain of exception delivered through a signal. The process is something like below.

void *thread2(void *arg)
{
    while(1) {
        does_other_jobs();
    }
    return NULL;
}

void *thread1(void *arg)
{
    pthread_create(tid2, ..., thread2, ...);

    while(1) {
        does_some_job();
    }
    pthread_join(...);

    return NULL;
}


int main()
{
    pthread_create(tid1, ..., thread1, ...);
    pthread_join(tid1, NULL);
}

Now, I want to have a way to kill/stop running of thread1 and its children. I tried to send SIGTERM to thread1, but the SIGTERM killed this process as a whole. What I did is as follows,

int main()
{
    sigset_t mask;

    pthread_create(tid1, ..., thread1, ...);

    sigemptyset(&mask);
    sigaddset(&mask, SIGTERM);
    pthread_sigmask(SIG_BLOCK, &mask, NULL);
    pthread_join(tid1, NULL);

    return 0;
}

So is there anyting wrong in above implementation? And is there a way to only stop running of thread1 and its children pthread?

As the question title suggests: I have set max_connections = 2 in my my.cnf file, but when I activate my mysql daemon, the thread count sits at 37. I am searching online but cannot find indication my expectations are wrong. Am I understanding the max_connections directive correctly ? Can anyone suggest a reason as to why this may not be limiting the thread count ? Attempts at a solution --------------------- 1) I query mysql global variables via the mysql CLI client:

| Variable_name              | Value                |
+----------------------------+----------------------+
| max_allowed_packet         | 67108864             |
| max_binlog_cache_size      | 18446744073709547520 |
| max_binlog_size            | 1073741824           |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| max_connect_errors         | 100                  |
| max_connections            | 2                    |
| max_delayed_threads        | 20                   |
| max_digest_length          | 1024                 |
| max_error_count            | 1024                 |
| max_execution_time         | 0                    |
| max_heap_table_size        | 16777216             |
| max_insert_delayed_threads | 20                   |
| max_join_size              | 18446744073709551615 |
| max_length_for_sort_data   | 4096                 |
| max_points_in_geometry     | 65536                |
| max_prepared_stmt_count    | 16382                |
| max_relay_log_size         | 0                    |
| max_seeks_for_key          | 18446744073709551615 |
| max_sort_length            | 1024                 |
| max_sp_recursion_depth     | 0                    |
| max_user_connections       | 2                    |
| max_write_lock_count       | 18446744073709551615 |

This confirms the my.cnf file is being correctly loaded as the max_connections variable is indeed set to 2. 2) As is visible from the output in (1), I have attempted limiting the max_user_connections variable also, but again, no luck. 3) I killed other server processes that I suspected could be querying the mysql daemon - httpd, php-fpm, but this has not reduced the number of threads. System Specs ------------ My MySQL version is 8.3.0, and is a minimal install:

mysql-8.3.0-linux-glibc2.17-x86_64-minimal

Update ------ Running the query SHOW PROCESSLIST returns:

*************************** 1. row ***************************
     Id: 5
   User: event_scheduler
   Host: localhost
     db: NULL
Command: Daemon
   Time: 146457
  State: Waiting on empty queue
   Info: NULL
*************************** 2. row ***************************
     Id: 11
   User: root
   Host: localhost
     db: NULL
Command: Query
   Time: 0
  State: init
   Info: SHOW PROCESSLIST
2 rows in set, 1 warning (0.00 sec)

I found more helpful running SELECT * FROM performance_schema_threads\G, which returned information about many tasks mysqld is executing. I had a suspicion this list of tasks would correspond to the number of threads and running:

SELECT COUNT(*) FROM performance_schema.threads\G

Returns:

38

Which nicely corresponds to the number of threads - I suspect the extra task corresponds to the master process. In the terminal:

pstree | grep sql
|-mysqld---37*[{mysqld}

Reading through the task names returned by performance_schema.threads, I gather these threads are necessary for MySQL to function as their names are io_read_thread,io_write_thread,log_writer_thread and similar. Setting max_connections works as expected - setting max_user_connections=2 and attempting to open a third client as root returns:

ERROR 1203 (42000): User root already has more than 'max_user_connections' active connections

However, if max_connections is set to 2, while max_user_connections is at 6, I can have 3 mysql clients open at once with user root. When I try and open a fourth client as root, I receive:

ERROR 1040 (HY000): Too many connections

How does a limit of three client sessions under one user arise from my.cnf limits of:

max_connections = 2
max_user_connections = 6
thread_cache_size = 2

? I am continuing to read up MySQL documentation but am yet to find an explanation. If someone more experienced can offer clarity, I would be greatly appreciative. How do these settings affect connection (and so thread) number ?

I'm programming an embedded real-time Linux device with a 4 core ARM CPU. There is a requirement for a periodic computation at 10 kHz that should not jitter too much and should never be lost. My POSIX thread can read a HW-provided 10 kHz toggle register in a busy loop and perform the computation whenever the bit is toggled. In order to keep the SCHED_RR scheduler from interrupting the pthread I set the CPU affinity to core 2 exclusively for this thread, and the priority to 99 (maximum). A handful of other threads have CPU affinity set to cores other than 2 and priority 50. But there's still a systemd running and a bunch of other processes. Is this enough to keep the thread from ever being interrupted by the scheduler? If not, is there a way to achieve this?

I write some threads of my app to a Linux cpu cgroup, created by me, explicitly (let us talk e.g. about v1 for now, but if you know a way for v2, that would be also great). However, I see that descendant threads (created with pthread_create() called by their parent thread, which is written to the cgroup explicitly or again after its parent thread) also appear in the cgroup without me writing them directly. This affects the app not in a good way. Some threads get to the cgroup unexpectedly. You need be always aware of this caveat and be careful e.g. with thread pools etc. Could you, please, tell if there is a way to solve this problem? E.g., maybe is there a way to forbid descendant threads from getting into their parent's cgroup automatically? Any help appreciated.

I was writing a multi-threaded C program using pthread library. The program calls the malloc() from a thread and the main-thread. When I inspected the memory address returned by malloc(), the address returned by the malloc() in the main-thread was usual address (like 0x80874a0) which is the address of heap section of the program. But the address returned by the malloc() in another thread (created by pthread_create()) is kind of unusual the address was high in the address space (0x7ffa87000a60 looking kind of like address in stack section). After analyzing the address of some stack variable of that thread, it looks like the address returned by the malloc() is near the stack for that thread. I am confused because as far as I know the **heap** section of a program is shared by all threads in that program, so any call to malloc() should return addresses kind of close together. It should return addresses starting from one address. But for sure it isn't the case.

During the porting of an application form Linux to FreeBSD I came up with the following problem. I need to get all thread id of all threads running inside my application. In terms of PThreads, I need an instance of an pthread_t array which contain all threads in my program (either PThreads or OpenMP) to send a signal using pthread_signal to them. The current Linux implementation uses a non portable workaround by traversing the procfs to obtain all pids of a process: int foreach_pid(void (*func)(pid_t, void *aux),void*aux){ DIR *proc_dir; char dirname; pid_t pid; if ( ! func ) return -1; snprintf(dirname, sizeof(dirname), "/proc/%d/task", getpid()); proc_dir = opendir(dirname); if (proc_dir) { /* /proc available, iterate through tasks... */ struct dirent *entry; while ((entry = readdir(proc_dir)) != NULL) { if(entry->d_name == '.') continue; pid = atoi(entry->d_name); func(pid, aux); } closedir(proc_dir); return 0; } else { return -1; } } and uses the kill function to send the signals to all threads via their process ids. Obviously, this is not a portable to solution because even if linprocfs is mounted under FreeBSD it does not provide the *task* directory. So what I am searching for is a routine/an interface/a library/a syscall to have a portable way to obtain similar information. Either as pid_t or preferable as pthread_t.

I wrote a simple program with a thread which runs on a CPU core. It spins kind of aggressively, and it takes 100% of the CPU core. I can see that with top + 1. After N minutes, I would like to be able to know: How many times has the kernel preempted (interrupted) my running thread?

I am confused by the terminology used to describe Linux signal delivery. Most texts say things like "the signal is delivered to the process" or "the signal is delivered to the thread". It is my understanding that a signal is "delivered" to a signal handler, which resides in a process, when the kernel calls that handler. The process itself is running asynchronously, and this "delivery" process is akin to a CPU calling an interrupt handler. The interrupt handler (signal handler) is not the process thread, nor any thread running under that process, correct? It is a separate thread of its own started by the kernel. So the signal is not delivered to a thread or a process, but is delivered to a signal handler residing in the process and not necessarily associated with any specific thread. If this is not correct, please tell me, for example, the association between the signal handler and a pthread that justifies the terminology of "signal delivered to a pthread".

I'm using simple-scan on Debian and it is now always crashing. It worked fine a few months ago. I suspect that something got upgraded (I'm running bullseye) and broke things. The output from simple-scan says:

simple-scan: thread-watch.c:165: avahi_threaded_poll_quit: Assertion `pthread_equal(pthread_self(), p->thread_id)' failed.
Abort

I tried running ldd /usr/bin/simple-scan to make sure all the packages associated with all the libraries are recent, including libc6. I also tried running with simple-scan -d, but the debug output proved useless. I also tried strace /usr/sbin/simple-scan to look at all the shared libraries that were being loaded and they all had recent versions. I noticed that the libavahi shared libraries are loaded dynamically (i.e., not visible via ldd) by simple-scan. So, I made sure that those were also recent. I also tried xsane, but it has the same problem. Perhaps unrelatedly, I see the following messages in my system log file:

avahi-daemon: Too many clients, client request failed.

scanimage does not crash, but it fails in an unrelated way. I am at my wit's end and don't know what else can be done.

I am trying to build 32bit versions of two programs, and both shows the same error message /usr/bin/ld: cannot find /media/34GB/Arquivos-de-Programas-Linux/Glibc-2.17-32bit/lib/libpthread.so.0 I certainly understand why it cannot find it, as I moved Glibc dir from the above path to: /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libpthread.so.0 However, I have no idea as to why ld is looking for libpthread in this wrong path. I have a bunch of symbolic links to Glibc lib files in /usr/lib32, but these are all correct, with the one responsible to libpthread pointing to the second path above. I executed ldconfig but to no avail When I tried to build the first program, I thought some libraries that I was passing to configure had this old path hard linked on it, and so it was the cause. However, when I run configure on the second program, I don't need to pass any library to it for the same error message to show up, so the cause is likely other. So, I am open to any suggestion as to why is ld looking for libpthread in the old directory.

I’m trying to reimplement in a backward-compatible way the RobotC API from C (although some details would better fit or would be easier with C++), and trying to reimplement their multithreading API in some portable way, so I try to use sched_get_priority_max(2) and sched_get_priority_min(2). But on one hand nice(1) and sched(7) say priority is between -20 (highest priority) and 19 (lower priority), on another hand, the former man pages stated that: > […] numerically higher priority values are scheduled before > processes with numerically lower priority values. Thus, the value > returned by sched_get_priority_max() will be greater than the value > returned by sched_get_priority_min() which would mean the opposite: positive value being of higher priority and negative of lower priority (it also gives the example of real-time policies where priority is between 1 and 99). What is going to be returned by sched_get_priority_max and _min? what should I use with pthread_attr_setschedparam(3)? I have three values defining my custom priority range: the low priority (kLowPriority, set to 0), the high one (kHighPriority, set to 255) and the default one (kDefaultPriority, set to 7). Ideally I suppose the default being 0 for the scheduling policies having a default, kDefaultPriority/7 should become 0, kHighPriority/255 the highest priority (19? 99? whatever sched_get_priority_max(3) returns) or maybe the highest priority that can be assigned if unpriviledged? and then kLowPriority either 0 ± kDefaultPriority, either the lowest priority …what would be the more reasonable? Currently I think I do it this way: pthread_attr_t attr; pthread_t thread; struct sched_param param; const int policy = sched_getscheduler(0), sched_high_prio = sched_get_priority_max(policy), // 19, sched_low_prio = sched_get_priority_min(policy), // -20, sched_range_prio = sched_high_prio - sched_low_prio; pthread_attr_init (&attr); pthread_attr_getinheritsched(&attr, PTHREAD_INHERIT_SCHED); pthread_attr_getschedparam (&attr, ¶m); param.sched_priority = -(((nTaskPriority - kLowPriority) * sched_range_prio / kHighPriority) + sched_low_prio - kDefaultTaskPriority); PS: I’m not sure if the best place to ask this question about POSIX API is here or stackoverflow , so I’m doing both, please delete my post or ask me to delete if you think it’s at the wrong place. EDIT: SO post deleted.

I am making an X application which contains a digital clock. The clock displays the current time in the format of "hh:mm". I want to master Xlib, so I want to use only Xlib (no other toolkits). The clock has to refresh once in a minute. For the refreshment of the clock, I came up with three implementations, but I cannot judge which is the best one. Please tell me which is the best. And, if there are other better implementations, please tell me. The first implementation refreshes the clock from inside the event loop. The second and third implementations refresh the clock from outside the event loop. The first implementation is as follows: in the event loop, I use XEventsQueued or XPending to know the number remaining events. If there remains no events, check the current time, and if 1 minute or more passed since the last refreshment, I refresh the clock. If there remains some events, I process other window events. The second implementation is as follows: I use setitimer with the interval of 1 minute. The signal handler catch SIGALRM and refresh the clock. The third implementation is as follows: I use pthread. The thread function refreshes the clock and sleep 1 mintes, and does the same thing forever. The first implementation is the most simple. But I am afraid that it frequently repeats the event loop and consumes the CPU power.

I'm learning about the Linux process scheduler and have been reading through the pthread_setsched function: https://man7.org/linux/man-pages/man3/pthread_setschedparam.3.html One thing that had surprised me is that threads are allowed to modify their own priority / class. I can see how this makes sense for configuring certain multi-thread applications (e.g. producers and consumers), however, it seems like a system stability risk that any process can just request to set its own priority. What's stopping my helloworld.out from requesting SCHED_FIFO at the highest priority? This could completely lock up the system. So what mechanisms are in place to prevent a process from have full reign of the scheduler? It seems like a system error EPERM can be set, however, where is this configured?

If I know the TID of an arbitrary thread that is running on my system, I can easily compute its pthread cpu clock ID. But would I be able to call clock_gettime from my program and get its CPU time? My experiments suggest it's not possible, but I wasn't able to find the sources to confirm this. If not, is there a way to get hi-res CPU time for a given thread? /proc/stat gives that information but I'd like something more accurate than jiffies.

Following are the Linux Process states;

R: running or runnable, it is just waiting for the CPU to process it
S: Interruptible sleep, waiting for an event to complete, such as input from the terminal
D: Uninterruptible sleep, processes that cannot be killed or interrupted with a signal, usually to make them go away you have to reboot or fix the issue
Z: Zombie, we discussed in a previous lesson that zombies are terminated processes that are waiting to have their statuses collected
T: Stopped, a process that has been suspended/stopped

I have two questions; (1) When a mutex_lock() is called in a process/thread, and if it is waiting for the lock to acquire(another thread locked the mutex already), will the process go to

or

? (2) I know that spinlock() will put the process in busy waiting and it checks to see if the lock is unlocked by other thread. However in mutex_lock() how it knows that the lock is unlocked and it is available to lock and proceed? i.e; How the process wakes up from

to lock the mutex when it is available(unlocked by other thread)?

My default stack size (according to ulimit -s) is 8192 kB, so naturally the code below segfaults when I try to run it. Also, naturally, it works fine if I do a 'ulimit -s 9000'. However, when I do a 'ulimit -s unlimited' the code segfaults again. Any ideas what is going on here? If it's useful, I'm running Debian 10 with kernel 4.19.0-6 and gcc version Debian 8.3.0-6.

#include 
#include 
#include 

void* wait_exit(void*)
{
  char bob[8193*1024];
  return 0;
}

int main()
{
  pthread_t t_exit;
  int ret;
  
  if((ret = pthread_create(&t_exit,NULL,wait_exit,NULL)) !=0)
  {
    std::cout<<"Cannot create exit thread: "<