I wonder how create a CSP library for obj-c, that work like Go's channels/goroutines but with idiomatic obj-c (and less boilerplate than actual ways).
In other languages with native courutines and/or generators is possible to model it easily, but I don't grasp how do the same with the several ways of do concurrent programing in obj-c (plus, the idea is have "cheap" threads).
Any hint about what I need to do?
I would look at the State Threads library as it implements roughly the same idea which underlies the goroutine switching algorythm of Go: a goroutine surrenders control to the scheduler when it's about to sleep in a syscall, and so the ST library wraps OS-level file descriptors to provide their own FD-like objects which can be read from (and/or written to) but instead of blocking the whole process these operation transfer control to other light-weight threads managed by the library.
Then you might need a scheduler more advanced than that of the ST library to keep OS threads busy running your SPs. A no-brainer introduction to the Go 1.2 scheduler is here, and it contains a link to a more hard-core design document. The rest is in the Go's source code.
See also this answer on SO.
Create operations, e.g. for an example consider this process:
process x takes number from east, transforms it to a string, and gives it to west.
That I could model it with an object that keeps an internal state of x (consisting of number and string) and the following operations:
east-output, operation defined somewhere else by east process logic
x-input, operation that depends on east-output. It copies number from east-output's data structure into x's data structure
x-output, operation that depends on x-input. Its content is defined as purely internal transformation - in our example, stringWithFormat...
west-input, operation that depends on x-output, etc.
Then you dump the operations into NSOperationQueue and see what happens (does it work, or are there contradicting dependencies...)
Related
We received an assignment where we have to create a distributed file system. This file-system should have multiple servers, each performing a certain function.
This question relates to the lock-server, which is used to prevent two people from writing to the same file at once. Every attempt to access a file generates a thread, that when finished provides access to the requested file. If a file that is not currently free is accessed, the thread should be BLOCKED until the lock is released. With JAVA I would probably just use the wait() and notify() methods, but these are not present in Kotlin (I know you can force them in by casting but it is frowned upon). Is there an elegant way to do this? We are not limited in what libraries we can use so if you know one that could fit I will gladly check it out. Right now the one I think would fit the most is the ReentrantLock, but I am looking for more possibilities.
I have also checked out this list: https://stackoverflow.com/a/35521983/7091281
But none of the ones listed seemed to fit - I specifically need to block the thread, while everything I find does the exact opposite.
BTW the different parts of the system are supposed to communicate via RMI. Also while we can go our own way, it is encouraged to use threads instead of coroutines. (we are supposed to work in JAVA but we were allowed to use kotlin and scala)
If you want to use pure Kotlin, you could leverage coroutines, and more specifically its Mutex for locking.
More info can be found at the Kotlin docs, regarding Shared Mutable State and Concurrency
This question is related to diagraming a software process. As an electrical engineer, much of the software I do is for embedded micro-controllers. In school, we learned to illustrate our algorithm using a flowchart. However, nowadays, many of my embedded projects are heavily interrupt-driven where the main process runs some basic algorithm a variety of interrupt sources provide its stimulus. So, my question is, what are some diagramming techniques that I can use to illustrate my process such that future developers can understand what I am doing easily and get involved in development?
Here are some key features that I am looking for:
Shows data structures and how data is passed between processes & interrupts
Shows conditions that cause each interrupt
Shows how data is gathered and passed through a downlink
Shows how command messages are received, parsed, and executed
Ideally is well suited for hierarchical breakdown into smaller processes with greater levels of detail
I've always seen interrupt timing drawn as follows:
Or inline line so:
But I prefer the former as it gives more room for annotation.
In response to your comment, perhaps a UML state machine diagram (with some adaptation) may be closer suited to your purpose:
There are many of interesting approaches you can find in diagram drawing. I will post a few here. You will find a lot of Operation System and Architecture scpecific names in there such as register , event, function names and etc. It is more for representation so far, right? So he we are.
Use UML class diagrams for showing data structures. Use sequence diagrams to show interactions between classes and interrupt service routines (showing function calls only). Use activity diagrams to show how interrupts interact with processes (signals are good for this). An activity diagram can also be used to show the process of receiving data, parsing it, and dispatching it. This can also be represented in a static view by a package diagram where the command handler is in one package and the command parser is in another, connected by a dependency line. Use cases are good for a high level view of functionality.
The main point is that UML supports many different views (static, dynamic, logical, deployment) into your system. Don't try to express everything at once.
The diagram below shows an example of an interrupt to a process.
In smalltalk, you're able to save the state of the world into an image file. I assume this has to do with Smalltalk's ability to "serialize" itself -- that is, objects can produce their own source code.
1) Is this an accurate understanding?
2) What is the challenge in adding this ability to modern languages (non-lisp, obviously)?
3) Is "serialization" the right word? What's the correct jargon?
It's much simpler than "serializing". A Smalltalk image is simply a snapshot of the object memory. It takes the whole RAM contents (after garbage collecting) and dumps it into a file. On startup, it loads that snapshot from disk into RAM and continues processing where it left off. There are some hooks to perform special actions on snapshot and when resuming, but basically this is how it works.
(added: see Lukas Renggli's comment below for a crucial design choice that makes it so simple compared to other environments)
Extending upon Bert Freudenberg’s excellent answer.
1) Is this (ie object's ability to serialize their own source code) an accurate understanding?
Nope. As Bert pointed out a Smalltalk image is simply a memory snapshot. The single-source-of-truth of both Smalltalk objects and Smalltalk programs is their memory representation. This is a huge difference to other languages, where programs are represented as text files.
2) What is the challenge in adding this ability to modern languages (non-lisp, obviously)?
Technically, bootstrapping an application from a memory snapshot should be possible for most languages. If I am not mistaken there are solutions that use this approach to speedup startup times for Java applications. You'd have to agree on a canonical memory representation though and you'd need to make care to reinitialize native resources upon restarting the program. For example, in Smalltalk, open files and network connecting are reopened. And also, there's a startup hook to fix the endianness of numbers.
3) Is "serialization" the right word? What's the correct jargon?
Hibernation is the term.
Crucial difference is that Smalltalk treats Program just as bunch of objects. And IDE is just a bunch of editors editing those objects, so when you save-load image, all your code is there just as when you left off.
For other languages it could be possible to do so, but I guess there would be more fiddling, depending on how much reflection there is. In most other languages, reflection comes as add-on, or even afterthought, but in Smalltalk it is in the heart of the system.
This happens already in a way when you put your computer to sleep, right? The kernel writes running programs to disk and loads them up again later? Presumably the kernel could move a running program to a new machine over a network, assuming same architecture on the other end? Java can serialized all objects also because of the JVM, right? Maybe the hurdle is just architecture implying varied memory layouts?
Edit: But I guess you're interested in using this functionality from the program itself. So I think it's just a matter of implementing the feature in the Python/Ruby interpreter and stdlib, and having some kind of virtual machine if you want to be able to move to a different hardware architecture.
I'm developing a game in Groovy and I'm thinking of using closures extensively to make architecture cleaner.
For example, to implemented status effects (such as poisoning) the Player object will have a list of closures to execute each game turn. These will have to be serialized when saving the game.
Is it generally a good idea to store closures in objects that will need serialization? Or should I opt for a more traditional architecture (e.g. storing a list of StatusEffect objects)?
Having a list of closures to execute each game turn sounds like a really nice idea :-)
Serialising Closures is perfectly possible. Since Groovy 1.8.5, it has been made easier as the two methods dehydrate and rehydrate were added to Closures (so that the owner, thisObject and delegate can be stripped before serialisation)
But I have issues with native java Serialisation for the saving of data. For sending short-lived data between systems, it can be great (but even then I would look at protocol buffers or thrift)
Consider what happens if you need to update your game? If there is a bug in the poisoned affect, then every user that has saved with the buggy poisoned closure in their save file will keep that bug until it wears off. In a multiplayer game, it would also be possible for people to manipulate their save game files to give themselves unexpected or unwanted powers (as the functionality for the powers themselves would be stored in the file). I could see manipulating a poison affect so it adds HP instead of removing them could be beneficial ;-)
In short, I guess what I'm saying is that I would write out a character sheet, with IDs for things that are affecting the user, inventory, score, etc, and then check and apply the closures as the file is read in.
Both 2 libs are designed for async i/o scheduling, and both engages epoll on linux, and kqueue on FreeBSD, etc.
Except superficial differences, I mean what is the TRUE difference between these two libraries? regarding to architecture, or design philosophy?
As for design philosophy, libev was created to improve on some of the architectural decisions in libevent, for example, global variable usage made it hard to use libevent safely in multithreaded environments, watcher structures are big because they combine I/O, time and signal handlers in one, the extra components such as the http and dns servers suffered from bad implementation quality and resultant security issues, and timers were inexact and didn't cope well with time jumps.
Libev tried to improve each of these, by not using global variables but using a loop context for all functions, by using small watchers for each event type (an I/O watcher uses 56 bytes on x86_64 compared to 136 for libevent), allowing extra event types such as timers based on wallclock vs. monotonic time, inter-thread interruptions, prepare and check watchers to embed other event loops or to be embedded and so on.
The extra component problem is "solved" by not having them at all, so libev can be small and efficient, but you also need to look elsewhere for an http library, because libev simply doesn't have one (for example, there is a very related library called libeio that does asynchronous I/O, which can be used independently or together with libev, so you can mix and match).
So in short, libev tries to do one thing only (POSIX event library), and this in the most efficient way possible. Libevent tries to give you the full solution (event lib, non-blocking I/O library, http server, DNS client).
Or, even shorter, libev tries to follow the UNIX toolbox philosophy of doing one thing only, as good as possible.
Note that this is the design philosophy, which I can state with authority because I designed libev. Whether these design goals have actually been reached, or whether the philosophy is based on sound principles, is up to you to judge.
Update 2017:
I was asked multiple times what timer inexactness I refer to, and why libev doesn't support IOCPs on windows.
As for timers, libevent schedules timers relative to some unknown base time that is in the future, without you knowing it. Libev can tell you in advance what base time it will use to schedule timers, which allows programs to use both the libevent approach and the libev approach. Furthermore, libevent would sometimes expire timers early, depending on the backend. The former is an API issue, the latter is fixable (and might have been fixed since - I didn't check).
As for IOCP support - I don't think it can be done, as IOCPs are simply not powerful enough. For one thing, they need a special socket type, which would limit the set of handles allowed on windows even more (for example, the sopckets used by perl are of the "wrong" type for IOCPs). Furthermore, IOCPs simply don't support I/O readyness events at all, they only can do actual I/O. There are workarounds for some handle types, such as doing a dummy 0-byte read, but again, this would limit the handle types you can use on windows even more and furthermore would rely on undocumented behaviour that is likely not shared by all socket providers.
To my knowledge, no other event library supports IOCPs on windows, either. What libevent does is, in addition to the event library, it allows you to queue read/write operations which then can be done via IOCPs. Since libev does not do I/O for you, there is no way to use IOCPs in libev itself.
This is indeed by design - libev tries to be small and POSIX-like, and windows simply does not have an efficient way to get POSIX-style I/O events. If IOCPs are important, you either have to use them yourself, or indeed use some of the many other frameworks that do I/O for you and therefore can use IOCPs.
The great advantage of libevent for me is the built-in OpenSSL support. Bufferevent interface, introduced in 2.0 version of libevent API, handles the secure connections almost painlessly for the developer.
May be my knowlege has gone out of date but it seems like libev does not support this.
Here are souce code link,
libev: https://github.com/enki/libev
libevent: https://github.com/libevent/libevent
I find the latest commitee of libev is 2015, but the livevent still have commitees untill July 2022, so a library have persons to maintain it is also important.