Comments (13)
First of all: thank you for your work try porting libcppa to ARM! What system are you using? What compiler version?
Yielding is an essential component of the cooperative actor scheduling. If this doesn't work, the scheduler doesn't work. That's why test spawn is stuck in a deadlock. Either the ucontext API doesn't work as expected or the yield interface doesn't work. The yield interface uses "__thread" variables of GCC, see src/yield_interface.cpp. Is this feature available on ARM?
If the yield interface does work correctly, then you might try to fix the cppa::fiber implementation for ARM. It uses "ucontext.h" on Unix machines.
Good luck!
from actor-framework.
System is a Tegra 2 (in a Trim Slice - http://trimslice.com/) running Arch Linux ARM with GCC 4.6.2. Kernel is 2.6.38.3 (I can't upgrade to 3.1 due to some hardware support issues).
I recall reading at some point that the ucontext API is deprecated? I'll look into it.
It seems safe to assume that GCC intrinsics would either be available or cause an error; anything else would be a broken design.
I'll take a closer look.
from actor-framework.
It looks like the ucontext API has been removed from the POSIX standard, but I don't know whether that's considered deprecation or not.
As for this specific issue, setcontext seems to be a noop on my system. I'll see if I can figure out why.
from actor-framework.
As far as I can tell, because ucontext has been removed from the POSIX standard, it will remain on platforms where it's already implemented but will not be ported to new platforms. Apparently ARM falls into the latter category. There are supposed to be linker warnings that getcontext/setcontext will always fail, but I don't see them for some reason (even when building 5 line ucontext demo applications).
I'll see if there's any effort inside glibc to get this API implemented on ARM, but it seems the general recommendation is to fall back to setjmp/longjmp and friends and avoid ucontext.
from actor-framework.
Well, the default actor implementation needs an own stack. Thus, setjmp/longjmp doesn't help much. What about GNU pth? It should be relatively easy to port libcppa from ucontext to GNU pth if it does work on ARM.
from actor-framework.
I just wrote a sample program, and pth does seem to be working. Given that the current attitude in glibc is that ucontext is deprecated and should be avoided, pth does look like a good alternative.
On the other hand, pth doesn't look like it runs on Windows (but ucontext probably doesn't either).
from actor-framework.
I just read the GNU pth documentation for porting libcppa to it, but it's not possible since GNU pth implements its own single-threaded scheduling. Sorry! I thought pth provides primitives for context switching but its a different approach to ucontext. I will search for an alternative. I'm really sorry for wasting your time. :/
Btw, Microsoft implemented its own user-space threading library called fibers: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682661(v=vs.85).aspx
It's not an issue and there is already a port included in libcppa. However, the problem with Windows right now is the lack of a lot C++11 features in the Visual Studio compiler.
from actor-framework.
Alright, well, I don't know of any alternatives, but I'll poke around and see if I can find anything. I see what you mean about scheduling, though.
As for my time, don't worry about it. This library looks to be worth some of my time :)
from actor-framework.
I have yet to try it out, but this looks like it implements the abstraction you're looking for: http://www.xmailserver.org/libpcl.html
I don't know how well supported it is.
EDIT: Just tried it, and fortified glibc doesn't like it on ARM. I'll see what I can do...
EDIT AGAIN: Gah, my bad, forgot to disable source fortification when building the library (which seems to be standard practice). Looks good.
from actor-framework.
Things like libpcl, libtask, etc. are too high level. All libcppa needs is swapcontext() functionality. In particular, libcppa needs a library without internal state. Thus, everything providing init() or something similar is out.
However, I browsed the GNU pth sources and it does implement its own context switching:
extern int pth_uctx_create(pth_uctx_t *);
extern int pth_uctx_make(pth_uctx_t, char *, size_t, const sigset_t *, void (*)(void *), void *, pth_uctx_t);
extern int pth_uctx_switch(pth_uctx_t, pth_uctx_t);
extern int pth_uctx_destroy(pth_uctx_t);
I will try to port libcppa to pth using only the context switching functionality of it. I guess it should be straight forward and should run on ARM since you already tested it successfully. :)
from actor-framework.
I've ported libcppa to pth and poked a bit around with it. In short: it doesn't work. The unit test of the yield interface is successful, but as soon as you try to spawn an actor, your application is dead.
Pth uses signal handlers for context switching. It's a very tricky algorithm by the way (see www.gnu.org/s/pth/rse-pmt.ps). However, it fails as soon as you have more than one kernel thread. Even if one synchronizes calls to the context switching function, since it needs access to some static data.
And a single-threaded libcppa implementation is pretty useless. I would love to see libcppa running on ARM, but I don't have the time (or hardware) yet to look for an alternative ucontext implementation, resp., implement one of my own.
However, libcppa is LGPL software. Feel free to fork it and try porting it yourself (if you have the time to do so). fiber.cpp is the only file you'll need to modify.
from actor-framework.
Thanks for looking into this, and sorry it didn't wind up working.
pcl and pth both use setjmp and longjmp, along with some custom code, to duplicate swapcontext on platforms where it's not available. When I've got some time (which I probably will in the next week or so), I'll see if I can duplicate what they're doing well enough to get things working.
from actor-framework.
You can disable context switching now by using ./configure CXXFLAGS="-DCPPA_DISABLE_CONTEXT_SWITCHING".
Be aware that this will cause each actor to run in its own thread unless you're using event-based actors. Btw, you always should use event-based actors anyways, since they run faster and scale better. However, a subset of libcppa is better than nothing, isn't it?
from actor-framework.
Related Issues (20)
- json_builder issue HOT 1
- Heap-use-after-free in blocking_actor test suite
- configuration options for length field of length prefix framing HOT 2
- Regression in caf::io::spawn_client HOT 2
- Fix log severity when disposing connection acceptors
- Investigate frequent failures of caf-robot-stream-octet
- Investigate tests not running in some distros
- "http/client" example does not dispose of the connections after completing request
- Why is my request from a scoped_actor timing out when using the deterministic fixture? HOT 3
- Doxygen: much of the documentation has seemingly vanished HOT 6
- Websocket client closes the connection HOT 2
- Build errors with clang using c++23
- Crash in `run_actions` when calling `quit`
- Proposal: equivalent to `caf::json*` but for XML? HOT 5
- Possible bug/issue with flow_bridge_base::prepare_send() HOT 3
- Cannot run recent examples with vcpkg package HOT 2
- How to encapsulate a calculator to only provide a C function interface? HOT 3
- More broken Doxygen output
- print.hpp: Control characters not escaped correctly HOT 7
- missing close-frame when shutting down websocket server HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from actor-framework.