JarrettBillingsley
Evaluate libconcurrency as fiber replacement
You removed extended coroutine support saying it was impossible to have a portable version of it in C++.
However, extended coroutines are pretty awesome and you might want to consider using a library like libconcurrency.
It does sound pretty portable as well:
libconcurrency is based on a portable technique that modifies jmp_buf and uses setjmp/longjmp to save and restore contexts.
Hope you will re-consider your decision, because the lack of extended coroutines requires me to have many nasty work-arounds in my networking stuff.
I might look into it, though I'm planning on using sj/lj for exception handling as well (like Lua does), so I'm not sure how those would interact.
I'm curious though; I wasn't expecting the lack of extended coroutines to be much of an issue. What are you doing that needs them (or rather, is made much easier because of them)?
Being able to yield out of native methods would allow me to get to a much higher level of abstraction.
For example I do have a working MySQL binding for croc, but I can't use with this project, because it's using blocking sockets. However, if I was able to simply swap the underlying sockets it could use it like this:
- Croc code calls native code to query database
- Native code calls MySQL library functions
- Library issues write call to send data, then read call to wait for answer <--- blocking
Now I want that Croc Thread to yield out until data is available for the read call to finish so other threads can use that time. Similar problem with libCurl.
There was more to it, can't quite remember anymore. I think there was a problem with using callback based libraries like libevent.
I could, though keep in mind the D implementation is eventually going to be deprecated. :\
I know, that's why I'd love to have everything a little more abstract in my code. At the moment it's a weird mix of native Tango code and some Croc glue. It does work, but the problem is that it's almost no use, when I have to re-implement every in Croc, because I can't use native stuff. I did implement a working FastCGI client in Croc and can use that one to serve web pages through NGINX, but I wouldn't really want to implement the MySQL protocol myself. Even implementing a robust HTTP client is far from desirable :P
TL;DR: I would really like to hide as much as possible of the scheduling and network-event logic from Croc and re-use existing native code, but right now I can't do that.
Any chance you'll be bringing the extended coroutines back to the D implementation sometime soon?
Awesome, because I'm going on vacation soon and I'll need something to waste my time with :-D
Hahaha XD On Feb 24, 2013 1:25 PM, "Ligustah" [email protected] wrote:
Awesome, because I'm going on vacation soon and I'll need something to waste my time with :-D
— Reply to this email directly or view it on GitHubhttps://github.com/JarrettBillingsley/Croc/issues/80#issuecomment-14016392.
I might look into it, though I'm planning on using sj/lj for exception handling as well (like Lua does), so I'm not sure how those would interact.
I'm the author of libconcurrency, and I just came across this by accident. Instead of exception handling, you can consider going a more Erlangish/Go route and have coroutines like Erlang processes with fail-fast error handling.
Or you could implement exception handling in terms of coroutines, since exceptions are a restricted form of continuations/coroutines.
Good luck!
I've considered that. The more I've used exceptions the more I feel their limitations as an error handling mechanism. I've also become something of a Rust fanboy as of late and have been wanting to incorporate more Rust-isms.
Any chance you'll be bringing the extended coroutines back to the D implementation sometime soon?
_
Well I finally put them back in....... if you're even still using Croc/D anymore :\
Unfortunately not, mostly because of D, though. Using Go for most of my stuff now, which is basically exactly what I tried to build with my non-blocking Croc library.
EW GO Rust is better ;D
That's fine though. I'll just keep making a language no one uses ;_;
Haha, I was guessing you were still a Rust fanboy :P Haven't actually looked at it much, mostly because I just :heart: Go
In fact just the other day I wanted to have an easy to integrate scripting language for one of my Go projects, but they all sucked.
Sooooo, if you ever happen to make a Go port... ;D
Well that's kind of the hope of the C++ port! Then you can actually use Croc from languages other than D :P
Also I've had some exposure to C++11 and ooooooo it's not actually so bad anymore (though templates still blow)
I'd surely be up to writing some Go bindings once there's a C/C++ version that I can link against.
Pssssst there's a C++ port now, though there's no stdlibs and no doc comment compiler phase ;)
Awesome, I'll check it out later today. I hope it's super easy to compile :-D Am 13.02.2014 07:20 schrieb "Jarrett Billingsley" <[email protected]
:
Pssssst there's a C++ port now, though there's no stdlibs and no doc comment compiler phase ;)
— Reply to this email directly or view it on GitHubhttps://github.com/JarrettBillingsley/Croc/issues/80#issuecomment-34951613 .
It's on the cport branch, and I hope it is! I'm using cmake and developing using GCC on MinGW, so it should just be a matter of making a build dir, cd'ing into it, doing cmake .. -DCMAKE_BUILD_TYPE=Debug (or release) and then make.
$ cmake -DCMAKE_BUILD_TYPE=Debug
-- The CXX compiler identification is GNU 4.7.3
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bierlein/Croc
$ make
[ 1%] Building CXX object src/CMakeFiles/croc.dir/croc/api/array.cpp.o
In file included from /home/bierlein/Croc/src/croc/base/gcobject.hpp:5:0,
from /home/bierlein/Croc/src/croc/base/deque.hpp:6,
from /home/bierlein/Croc/src/croc/base/memory.hpp:5,
from /home/bierlein/Croc/src/croc/base/darray.hpp:6,
from /home/bierlein/Croc/src/croc/types.hpp:8,
from /home/bierlein/Croc/src/croc/internal/stack.hpp:4,
from /home/bierlein/Croc/src/croc/internal/apichecks.hpp:4,
from /home/bierlein/Croc/src/croc/api/array.cpp:3:
/home/bierlein/Croc/src/croc/base/sanity.hpp:28:0: error: "CROC_INTEGER_FORMAT" redefined
/home/bierlein/Croc/src/croc/base/sanity.hpp:27:0: note: this is the location of the previous definition
/home/bierlein/Croc/src/croc/api/array.cpp: In function ‘word_t croc::croc_array_newFromStack(CrocThread*, uword_t)’:
/home/bierlein/Croc/src/croc/api/array.cpp:21:3: error: format ‘%u’ expects argument of type ‘unsigned int’, but argument 5 has type ‘uword_t {aka long unsigned int}’ [-Werror=format]
compilation terminated due to -fmax-errors=2.
cc1plus: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/croc.dir/croc/api/array.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/croc.dir/all] Error 2
make: *** [all] Error 2
$ make
Scanning dependencies of target croc
[ 1%] Building CXX object src/CMakeFiles/croc.dir/croc/api/array.cpp.o
/home/bierlein/Croc/src/croc/api/array.cpp: In function ‘word_t croc::croc_array_newFromStack(CrocThread*, uword_t)’:
/home/bierlein/Croc/src/croc/api/array.cpp:21:3: error: format ‘%u’ expects argument of type ‘unsigned int’, but argument 5 has type ‘uword_t {aka long unsigned int}’ [-Werror=format]
/home/bierlein/Croc/src/croc/api/array.cpp:21:3: error: format ‘%u’ expects argument of type ‘unsigned int’, but argument 6 has type ‘uword_t {aka long unsigned int}’ [-Werror=format]
compilation terminated due to -fmax-errors=2.
cc1plus: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/croc.dir/croc/api/array.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/croc.dir/all] Error 2
make: *** [all] Error 2
Yes, Ubuntu 64bit
2014-02-13 8:14 GMT+01:00 Jarrett Billingsley [email protected]:
Ooh. 64-bit?
— Reply to this email directly or view it on GitHubhttps://github.com/JarrettBillingsley/Croc/issues/80#issuecomment-34953801 .
Alright. I'll have to see if I can do a 64-bit compile on my end and fix all the gunk. Using D for so long really makes you take stuff like "not having to deal with silly ancient vararg schemes" for granted :P
Haha, yea. Just update whenever you think it should compile on 64bit, I'll happily test again then.
BTW I have it compiling on 32- and 64-bit GCC on both Linux and Windows now, and virtually the whole thing is ported :O except croci (which will be easy) and addons and some other stuff
Awesome, I might give it a shot later today (most likely before the end of next week anyways).