comparing livuv, libevent or other implementations - libevent

We are currently using epoll based implementation on Linux. We plan to port our software to mac and hence looking for platform independent approach. I looked at libevent2 and libuv, both seem to be fitting our requirement. However, I would like to get suggestions from the people who have used both. I read some comparisons but they are quite old to be meaningful now:
libuv seems to be more popular than libevent
90% of our client connections are using TLS, and hence ease to use with SSL socket is mandatory. We are currently using boringssl and we are okay to use openssl too.
multithreading support
minimum buffer copy. It seems evbuffer in libevent is double copy approach which we'd like to avoid. They have peek API which may partially solve it but we yet to explore more.
Any other suggestions you might have on libevent, libuv or any other such options (no boost please).

Related

Easy way to find out whether a Posix API is implemented by an OS

While writing my code I thought of having a common implementation for all POSIX OSes as opposed to separate implementation for each OS. One of the POSIX API I use is posix_fallocate() and while testing I found it not being supported by MacOS.
Had I known this earlier I would have not used this API or have had separate implementations for each OS.
So my question is - what is an easy way to find support for a particular posix call in different OSes? Do people always have to search documentation for each target OS?
Thanks.
Looking at the documentation is a good start, but it often won't tell you when a particular function has been implemented, which is also important. For obscure platforms, it may be difficult to tell which older versions are still relevant, which makes it even harder to decide whether a dependency on a particular POSIX feature is acceptable.
The other question is whether a feature is implemented, but with substandard quality. posix_fallocate is an interesting corner case in this regard. The glibc implementation uses emulation if the file system lacks support for an actual low-level fallocate operation (such as NFS until recently):
https://www.gnu.org/software/libc/manual/html_node/Storage-Allocation.html
Depending on what your application does, this behavior might not be acceptable. Just checking header files and documentation might not reveal this (the Note part in the documentation above was added only recently, for example).
In the end, there isn't a good substitute for building and testing as early as possible on all relevant targets, but I understand that this is increasingly difficult for non-Linux targets.

Bonjour communication wrapper for Objective-C?

I've been using MYNetwork by the venerable Jens Alfke for an app of mine that allows devices to connect and share info over the network, it's actually a mission-critical part of the app. I tried writing my own wrapper for all of the C-level stuff you have to do for Bonjour, but it didn't work out so well, so I moved to MYNetwork.
It's been great so far, but the fact it's essentially opaque to me is causing trouble, as is that I want to move over to ARC once we can submit apps with it (there's a lot of Objective-C object references in structs, which ARC hates).
Can anyone recommend a similar wrapper, ideally that allows easy message passing between a client and a server over Bonjour as well as service discovery?
Just a thought- Would using ZeroMQ advertised and discovered by the stock NSNetService suffice? Separating the service pub/sub from the actual communication would allow you to use other bonjour libraries like Avahi on linux too. ZeroMQ is sufficiently simple to make wrapping trivial, yet powerful enough to cope with complex network topologies, fast.
I have experience with both technologies in isolation but not together although I see no reason why it wouldn't work. The only caveat right now is the limited body of collective experience of ZeroMQ use on iOS but I'd expect that to change over time.
You know you can disable ARC for specific files? So, you can just disable ARC for the library, and keep it on for your other files.
Disable Automatic Reference Counting for Some Files

what library is better between libcurl and chilkat?

i'm newbie in FTP connection programming in Cocoa. I found 2 library that i can choose for make my app, but i dont know what's the best between these libraries. The libraries are libcurl and chilkat . The problem is what benefit of each library? Did somebody compare it? or maybe can anyone tell me about your experience? Thank you
I don't have any experience with chilkat, but I can tell yout that libcurl is used in a lot of programming languages and is available on a lot of systems. In for example PHP or on a Mac curl is a great tool to use.
So I would advice libcurl if it's available on your platform. You will probably find more information about curl and it has proven itself on many other platforms.
Also interesting if you want to go with curl is curlhandle. It's a cocoa wrapper around the curl library. Probably very handy in your case, but I've no experience with it.
I can tell you that the difference between libcurl and chilkat is like this: (though you probably know by now)
Chilkat is like the chess game you buy at the store and libcurl is like the plastic in liquid form you buy that you can make any chess piece with.
Libcurl is a slightly abstracted sockets-connector and Chilkat handles everything you'd do, up to a certain amount, with that connection. You're either staring at bits or something "made those bits into an email". I'm about to buy Chilkat for some of the libs, I like the features, but at the same time I wish I had time to read the RFC's and play with the other stuff using libcurl. Anywho, hope that answer is worth something to someone.
Because this question is still ranking high on google i give you my experience.
I bought chilkat in 2015 and moved to libcurl later and my own implementation much later. Both are far from perfect. libcurl just shows it's age and some weak designs.
libCurl is an library that tries to implement all URL able protocols even if they are designed as stream protocol like FTP. Do yourself a favour and only use it with HTTP/HTTPS. It just does the transfer part. Which is not enough for handling. You would love to see at least mime and charset routines to use the downloaded files.
Chilkat is a toplevel library that tries to give you as much highlevel access as possible. It uses background threads in script languages where it is not easy to use. The problem is that the API is terrible, very little documented and total failure when you want to write a quality program. For example it returns requests as a string. There is no way for stream processing. Now imagine you download a large GB iso file, you wont be happy. It can return as a file but then you have to specify this at the begin of a request when you don't knwo the download size.
Also the code quality until proven otherwise is bad. There are a few chilkat source code snippets in the wild which you can find via google and they are pure madness. Ok we don't know how this old code has been refactored now. But it leaves a bad taste, remember this is closed source and there is not a single mention about corner cases, which protocol is implemented, which feature of protocols are implemented and so on. You are using a total black box.
Also it does not allow high performance and high value code. I used it to write a web crawler and it was much much slower then libcurl.
I later used the HTTP and SSH compoenents to automate some server/client management scripts and there it shines. You know both sides and can just test if they work together and don't get any surprises. Then it is indeed easy and better then using the broken python or ruby SSH.
But if you ever contact with another unknown server, Chilkat is not your library.

Simple, non-networking example of Twisted/PyGTK

I was struggling with getting some asynchronous activity to work under PyGTK, when someone suggested that I look at using Twisted.
I know that Twisted started as a networking framework, but that it can be used for other things. However, every single example I've ever seen involves a whole lot of network-based code. I would like to see an example of using Twisted for a simple PyGTK desktop app, without the needing to expend the extra mental effort of understanding the network aspect of things.
So: Is there a clean, simple tutorial for or example of using Twisted to create a GTK (PyGTK) app and perform asynchronous tasks?
(Yes, I've seen pbgtk2.py. It's uncommented, network-centric and completely baffling to a newcomer.)
Updated: I had listed various gripes with glib.idle_add/gtk.gdk.lock and friends not working properly under Windows. This was all reasoned out on the pygtk list - there's some trickery that is needed with PyGTK to get asynchronous behaviour working under Windows.
However, my point still stands that any time I mention doing asynchronous activity in PyGTK, someone says "don't use threads, use Twisted!" I want to know why and how.
Twisted to perform is asynchronous tasks in pygtk simply uses functions such as gobject.io_add_watch/glib.io_add_watch and gobject.timeout_add/glib.timeout_add (plus some others, you find them in the gobject and glib module), so there's not much difference in using raw pygtk functions or twisted if you don't need networking.
As an addition twisted has the same problems as pygtk with asynchronous tasks, twisted use the same loop as of pygtk and so it gets blocked if you perform some blocking task!
The best thing to do is to use one of the glib functions that are intended basically for handle such situations.
I've tested in an application the correct behaviour under windows of twisted+pygtk but I avoided to do blocking stuff (max reading from a large file, chunk per chunk basically using glib.idle_add or glib.io_add_watch, in the sense that twisted uses something like that).
For example I'm not sure that spawning process and processing stdout with glib.io_add_watch seems to not work. I've written an article on my blog that handle the performing of asynchronous processes in pygtk, not very sure that works on windows though it may depend on the version.

MPSOC : Which OS do you use and why?

I'm working on MPSOC, specially STM ST40 (SH4 base) and ST231 and I'm wondering which OS i can use on these to port a parallel application, I already had a look at STLinux which is the STM distribution of a Linux platform for their MPSOC (which unfortunately doesn't work well for ST231 coprocessors) and I also had a look at OS21 which is a task based OS.
Any information about other RTOS are warmly welcome! (specially those with libc and pthreads :)
Those 4 came to my mind:
MicroC/OS-II: Its free and simple, but i think there are too few good resources available
LibeRTOS: I can recommend that. I used it several times for different projects. It's good it's fast and the dual kernel concept is really well done.
RTLinux: Can't tell you much about that one. Only used it once for a very small project and didn't get deep "behind the scenes" But it was fast and reliable. (and very expensive)
VxWorks: Awesome OS... From Wikipedia:
multitasking kernel with preemptive and round-robin scheduling and fast interrupt response
Memory protection to isolate user applications from the kernel
SMP support
Fast, flexible inter-process communication including TIPC
Error handling framework
Binary, counting, and mutual exclusion semaphores with priority inheritance
Local and distributed message queues
Full ANSI C compliance and enhanced C++ features for exception handling and template support
POSIX PSE52 certified conformance
File system.
IPv6 Networking stack
VxSim simulator
Supports: C/C++/JAVA
If money is no problem: Use VxWorks! You can do anything: Upgrade your fridge, built a war machine or fly to Mars ;-)
Otherwise check out LibeRTOS...
If you really want ot use an RTOS, be prepared to use a native API that is way more efficient and streamlined than pthreads...
I have used Micrium's µC/OS-II on several projects, on SH4 and a couple of different ColdFires. I continue to recommend it for new projects today.
Micrium has just announced a major upgrade to be called µC/OS-III that will add unlimited preemptively scheduled threads, as well as a round-robin scheduler for equal priority threads. It doesn't appear to be for sale yet, however.
If you need the capabilities, they also have a FAT file system, a PEG graphical UI library, USB device and host, and TCP/IP available for additional license fees.
Source code to everything is included in the price, and I've always found their support to be friendly and knowledgeable.
With the processors you mention you seem to be into set-top boxes.
You have the choice between the ST Linux distro, which is not very stable and the OSXX distro, which is proprietary for ST, but much more stable and with nice tools for debugging and the like (I'm not so sure about OSCC and libc/pthreads)
Barebones/AMP - because it allows 100% control and it allows the lowest latency.
Using Linux or FreeRTOS is very comfortable but it comes with a price tag.