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
Related
Do you know if there is any open source task scheduler without the OS support?
Basically, we are looking for a lean scheduler that can schedule and preempt the tasks on our AM335X TI chipset based boards, which don't have any RTOS running on them.
There are no "portable" schedulers at that level, because the context switch functions are hardware-dependent. Therefore, you need a scheduler for your specific hardware (e.g., provided by TI in their development environments) or a very minimal RTOS.
There are RTOSs that are very minimal (a few KB of footprint) and can contain only the scheduler. Have a look for example at http://erika.tuxfamily.org. However, I'm afraid that your specific microcontroller is not supported.
Most simple RTOS kernels provide at least scheduling, synchronisation, and IPC. However since they are also provided as static libraries, what you don't use will not be included in your product. That said I find it difficult to think of a system where synchronisation, IPC and timer services would not be required or at least beneficial.
There are numerous such RTOS libraries including Segger embOS for example.
The only portable, hardware independent solution I know is Protothreads by Adam Dunkels. But it is not true multitasking anyway, just a nice syntax sugar on concurrent state machines. However it may help you in your task.
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.
My situation is quite simple: I want to run a MPI-enabled software on a single multiprocessor/core machine, let's say 8.
My implementation of MPI is MPICH2.
As I understand I have a few options:
$ mpiexec -n 8 my_software
$ mpiexec -n 8 -hosts {localhost:8} my_software
or I could also specify Hydra to "fork" and not "ssh";
$ mpiexec -n 8 -launcher fork my_software
Could you tell me if there will be any differences or if the behavior will be the same ?
Of course as all my nodes will be on the same machine I don't want "message passing" to be done through the network (even the local loop) but through shared memory. As I understood MPI will figure that out itself and that will be the case for all the three options.
Simple answer:
All methods should lead to the same performance. You'll have 8 processes running on the cores and using shared memory.
Technical answer:
"fork" has the advantage of compatibility, on systems where rsh/ssh process spawning would be a problem. But can, I guess, only start processes locally.
At the end (unless MPI is weirdly configured) all processes on the same CPU will end up using "shared memory", and the launcher or the host specification method should not matter for this. The communication method is handled by another parameter (-channel ?).
Specific syntax of host specification method can permit to bind processes to a specific CPU core, then you might have slightly better/worse performance depending of your application.
If you've got everything set up correctly then I don't see that your program's behaviour will depend on how you launch it, unless that is it fails to launch under one or other of the options. (Which would mean that you didn't have everything set up correctly in the first place.)
If memory serves me well the way in which message passing is implemented depends on the MPI device(s) you use. It used to be that you would use the mpi ch_shmem device. This managed the passing of messages between processes but it did use buffer space and messages were sent to and from this space. So message passing was done, but at memory bus speed.
I write in the past tense because it's a while since I was that close to the hardware that I knew (or, frankly, cared) about low-level implementation details and more modern MPI installations might be a bit, or a lot, more sophisticated. I'll be surprised, and pleased, to learn that any modern MPI installation does, in fact, replace message-passing with shared memory read/write on a multicore/multiprocessor machine. I'll be surprised because it would require translating message-passing into shared memory access and I'm not sure that that is easy (or easy enough to be feasible) for the whole of MPI. I think it's far more likely that current implementations still rely on message-passing across the memory bus through some buffer area. But, as I state, that's only my best guess and I'm often wrong on these matters.
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.
The documentation for libev (source) says that:
Kqueue deserves special mention, as at the time of this writing, it was broken on all BSDs except NetBSD (usually it doesn't work reliably with anything but sockets and pipes, except on Darwin, where of course it's completely useless).
It also mentions that:
The kqueue syscall is broken in all known versions - most versions support only sockets, many support pipes.
So, what are the limitations of kqueue? Where are these limitations documented? Initial research turned up references to kernel panics on older operating systems (Mac OS X 10.3) and complaints about incorrect/incomplete documentation. I don't know how reliable these sources are.
In particular, if kqueue does work reliably with sockets (AF_UNIX, AF_INET, and AF_INET6) then I don't mind. I am particularly interested in information about the Mac OS X and FreeBSD implementations.
On OS X, you shouldn't have problems with AF_UNIX, AF_INET, and AF_INET6. You will have problems if you want to use it with a PTY on OS X < 10.9, as PTYs are unsupported on those versions. There is some evidence that on OS X 10.9, PTYs are finally supported.
If you try to use the non-file descriptor notifications you will start to run into other limitations (eg AIO is unsupported).
I'm not familiar with FreeBSD's kqueue implementation. Perhaps someone else who is can add some information about it.
kqueue is perfectly working on FreeBSD, at least for networking. I have tested myself networking stuff with up to 180k connected, active sockets. I don't know for AIO .. haven't tested myself.