Is the XSI/System V IPC is outdated since we have POSIX IPC mechanisms available in Linux?
What kind of IPC (Sysv/Posix/other) is recommended for newer programs ?
POSIX for basics and dbus for “convoluted” :) things.
CORBA, humm, the only executables depending on it for me are libgnome-2.so and libreoffice, which is a whole lot less than dbus.
Related
After some research, I have found that on Linux, Tcl doesn't support Unix domain sockets at all.
In the absence of the Unix datagram sockets, what is the native(*) alternative for the reliable local message-based many-to-one communications in Tcl for the Unix-like systems? A limitation of text-only communication would be acceptable.
UDP is unreliable even if used locally. TCP is not message-based, and Tcl doesn't offer TCP_NODELAY option. Pipes are only one-to-one. FIFOs have poor async semantics and are (similarly to pipes) only one-to-one. SysV message queues lack poll() support but anyway are also not supported by the Tcl. I went through all the usual alternatives, but failed to find what fulfills the role of the Unix sockets in the Tcl.
(*) I have found the ceptcl, an external module, but it is neither a part of the Tcl nor is bundled with any Linux distro. As such it is not an acceptable option.
As stated before in this thread, unix_sockets cannot be part of the core package because of portability issues.
An implementation of Unix sockets as extensions here: https://github.com/cyanogilvie/unix_sockets
It works on Linux. Compilation tested successfully on Debian 10.
I know Rust can handle windows and *nix filesystems. I saw there is support to fork processes - is this also cross-platform? Would I be able to write a *nix daemon and a Windows service with the same codebase?
There is no such thing as fork on Windows (it uses CreateProcess instead).
More generally, Unix daemons and Windows services are very different (the latter has to comply with specific Windows interfaces), so you would need a significant abstraction layer if you want to share some code base. As far as I can tell, there is no library providing such an abstraction layer yet.
I know the signalfd(), eventfd() apis in linux OS.
But, I can't find this api in other OS (SunOS, Aix, HP).
Is it only support in Linux??
Both the signalfd and eventfd APIs are linux specific.
If you're trying to write portable code; then you're better off sticking to the POSIX APIs. Bear in mind that there can be vagaries in the implementations between platforms.
I'm aware of some Windows Thread Libs for Delphi(OmniThread Lib, BMThreads, etc).
But is there a lib that is built to be cross-platform and that can both be used under Delphi and FreePascal?
Although these are not links to threading libraries per se, the information on the following pages might (or might not) be of use when researching threading on Windows/Linux and MACOSX
Multithreading with Lazarus.
OSX Multithreading forum...thread.
Sorry couldn't offer anything more specific.
Both FPC/Lazarus and Delphi support TThread. FPC doesn't suppport TMREWS though (it does have the identifier but it is a simple lock).
But I assume you mean some thread pooling classes? What do you exactly need, and why is the Delphi built in support not enough?
D-Bus allows programs to communicate. How is this IPC implemented? Unix domain sockets, shared memory + semaphores, named pipes, something else? Maybe a combination?
I think it typically uses UNIX sockets. Under Linux, it may use "abstract namespace" Unix sockets, which are the same except they don't physically exist as visible files in the filesystem.
This is remarkably similar to the question DBus query. And the answer from Googling was sockets - either for TCP/IP or Unix Domain.
Apparently, IPC or TCP/IP:
http://www.freedesktop.org/wiki/Software/dbus
Update:
I mean, multiple IPC methods on different OS's, plus TCP/IP.
http://dbus.freedesktop.org/doc/dbus-daemon.1.html shows that the unix reference edition uses both unix domain sockets and tcp/ip.
There has been in the past some attempt to use netlink sockets directly from the kernel. More recently (announced during last LPC), some people are working at getting rid of D-Bus user-space daemon and putting D-Bus in the kernel, it will probably also use sockets, but maybe revive the netlink or other approaches.