Is there an alternative to signalfd (not available on Mac OS X)? I'm multiplexing I/O using select and would like to receive signals in some synchronized fashion.
man kqueue and look for EVFILT_SIGNAL there.
The descriptor returned by kqueue() should be poll()able/select()able. Events can be registered and read out using the kevent() call.
Original kqueue paper
P.S. I hope I'm not off by much, had no chance to use the kqueue myself yet.
Related
Which signal does gdb send when attaching to a process? Does this work the same for different UNIXes. E.g. Linux and Mac OS X?
So far I only found out, that SIGTRAP is used to implement breakpoints. Is it used for attaching aswell?
AFAIK it does not need any signals to attach. It just suspends the "inferior" by calling ptrace. It also reads debugged process memory and registers using this calls and it can request instruction single stepping (provided it's implemented on that port of linux), etc.
Software breakpoints are implemented by placing at right location instruction that triggers "trap" or something similar when reached, but debugged process can run full speed until then.
Also (next to reading man ptrace, as already mentioned) see ptrace explanation on wikipedia.
At the start, I wanna tell that I am not well versed with BSD internals. Now coming to the question.
There is a mechanism to have communication between user space and kernel space in bsd using kqueues. However, what I have understood is, we can have pre-defined events using kqueue and kevents. Can the same mechanism be used to define a custom event? For eg. In Linux I may be able to use netlink sockets. Please, correct me if I am mistaken in my understanding.
If Kqueue is not the correct solution then is there any other mechanism that allows me to notify user space from kernel. I am looking for something other than custom defined signals.
Thanks
You can send user-defined events using the EVFILT_USER filter. See kqueue(2).
My application need to download several web-pages simultaneously and i know this is possible in a single thread because of experience with epoll programming in linux. Currently i use CURL to interact with HTTP but...
update: Discovered the curl's MULTI-interface: http://curl.haxx.se/libcurl/c/libcurl-multi.html I think question is resolved (-;
The cross-platform way is to use select or poll which are specified by POSIX.
Alternatively, and more efficiently, you could use a library. The main advantage of a library is that it can do things way more effectively than select, by employing system-specific mechanisms.
For example, a nice network library would probably use:
epoll on Linux
kqueue on FreeBSD
/dev/poll on solaris
pollset on AIX
iocp on Win32
etc
I think you can use asio for C++ or libevent for C.
Is there any equivalent of IO COmpletion ports on Mac OS X for implementing Asynchronous IO on files....
Thank you....
Unfortunately, no.
kqueue is the mechanism for high-performance asynchronous i/o on OSX and FreeBSD. Like Linux epoll it signals in the opposite end of i/o compared to IOCPs (Solaris, AIX, Windows). kqueue and epoll will signal when it's ok to attempt a read or a write, whereas IOCPs will callback when a read or a write has completed. Many find the signalling mechanism used by epoll and kqueue difficult to understand compared to the IOCP model. So while kqueue and IOCP are both mechanisms for high-performance asynchronous i/o, they are not comparable.
It is possible to implement IOCPs using epoll or kqueue and a thread pool. You can find an example of that in the Wine project.
Correction:
Mac OS X has an implementation of IOCP like functions in Grand Central Dispatch. It uses the GCD thread pool and kqueue APIs internally. Convinience functions are dispatch_read and dispatch_write. Like IOCP the asynchronous I/O functions in GCD signals at the completion of an I/O task, not when the file descriptor is ready like the raw kqueue API.
Beware that GCD APIs are not "fork safe", and cannot be used on both sides of a POSIX fork without an exec. If you do, the function call will never return.
Also beware that kqueue in Mac OS X is rumored to be less performant than kqueue in FreeBSD, so it might be better for development than production. GCD (libdispatch) is Open Source however, and can be used on other platforms as well.
Update Jan 3, 2015:
FreeBSD has GCD from version 8.1. Wine has epoll-based IOCP for Linux. It is therefore possible to use IOCP design to write server code that should run on Windows, Linux, Solaris, AIX, FreeBSD, MacOSX (and iOS, but not Android). This is different from using kqueue and epoll directly, where a Windows server must be restructured to use its IOCPs, and very likely be less performant.
Since you asked for a Windows specific feature for OS X, instead of using kqueue directly you may try libevent. It's a thin wrapper to different AIO mechanisms and it work on both platforms.
Use Kqueue
http://en.wikipedia.org/wiki/Kqueue
The POSIX standard defines several routines for thread synchronization, based on concepts like mutexes and conditional variables.
my question is now: are these (like e.g. pthreads_cond_init(), pthreads_mutex_init(), pthreads_mutex_lock()... and so on) system calls or just library calls? i know they are included via "pthread.h", but do they finally result in a system call and therefore are implemented in the kernel of the operating system?
On Linux a pthread mutex makes a "futex" system call, but only if the lock is contended. That means that taking a lock no other thread wants is almost free.
In a similar way, sending a condition signal is only expensive when there is someone waiting for it.
So I believe that your answer is that pthread functions are library calls that sometimes result in a system call.
Whenever possible, the library avoids trapping into the kernel for performance reasons. If you already have some code that uses these calls you may want to take a look at the output from running your program with strace to better understand how often it is actually making system calls.
I never looked into all those library call , but as far as I understand they all involve kernel operations as they are supposed to provide synchronisations between process and/or threads at global level - I mean at the OS level.
The kernel need to maintain for a mutex, for instance, a thread list: threads that are currently sleeping, waiting that a locked mutex get released. When the thread that currently lock/owns that mutex invokes the kernel with pthread_mutex_release(), the kernel system call will browse that aforementioned list to get the higher priority thread that is waiting for the mutex release, flag the new mutex owner into the mutex kernel structure, and then will give away the cpu (aka "ontect switch") to the newly owner thread, thus this process will return from the posix library call pthread_mutex_lock().
I only see a cooperation with the kernel when it involves IPC between processes (I am not talking between threads at a single process level). Therefore I expect those library call to invoke the kernel, so.
When you compile a program on Linux that uses pthreads, you have to add -lphtread to the compiler options. by doing this, you tell the linker to link libpthreads. So, on linux, they are calls to a library.