Lthread - C coroutine lib with multicore support
github.com
github.com
(Even in the case of servers, there are a lot of cases where you would want to distribute a server, but not necessarily release the source code under GPL -- games like Minecraft, for instance, come to mind.)
Either way, write a polite note to the powers that be: "Our stance with respect to GPL software is causing us an estimated $15000/year cost in maintenance and development on project X". (Substitute $15000/year for a reasonable, justifiable estimate).
Your lawyers don't have to justify their GPL stance today. Make them. They'll probably win at the end in this company ... but change can arrive if enough people do this.
If he reconsiders and then decides that GPL indeed is the best license for his use case, that's great; but it's possible his original choice was suboptimal.
Edit: But I agree with Parfe - it could be kept GPL and dual licensed for $$, best of both worlds.
If it is "I want as many people to use it, regardless if I get anything in return, even credit, or even get to know about it" - then you should do BSD/MIT/Public domain. It makes sense for some projects, especially if they want to reach critical user mass, e.g. zlib, png, vorbis (the common theme I find that makes sense for this is "network effect")
If it is "I want people to be able to use it, but they have to give back to the community if they improve it", then LGPL is the right fit.
If it is "I want people who use it to share their use of it as a free product itself", use GPL (if you just want whoever distributes a binary to also distribute the source), or AGPL (if you want whoever makes the binary available for use, e.g. in a web server).
As a consumer, of course I like all libraries BSD - I never have to answer to everyone, everything is available to me for free, I can sell it, etc. That's the spoiled brat in me talking.
But as a mature member of the free software community, I ask everyone to consider GPL or even AGPL for code they release, unless they have a very good reason to do otherwise. Why would you want to support someone who does not support you back?
Specifically, I've so far only submitted patches (and signed over copyright when I did and the project requested), but if I ever release a full project on my own, it will definitely be GPL/AGPL with possibility for a proprietary license.
If GCC, which serves us all, had been BSD, it would probably not have been half as good as it is today: e.g. I suspect Sony would not have contributed back at all, IBM and Intel wouldn't have contributed as much, as many others. Furthermore, if GCC was AGPL, coverity would also have been free software.
ffmpeg/libav is the best media decoding library bar none (If you need control, the closest contender, Microsoft's stack, is not even close, and everyone else is much farther away). Many projects are violating ffmpeg terms left and right, but enough users respect the LGPL/GPL to make contributions significant, and everyone enjoys that. By the amount of projects that violate the terms, I suspect that a BSD license on ffmpeg would have been detrimental to the project.
Licensing something (A|L|)GPL still allows you to negotiate specific licenses for some compensation, e.g. patent protection from the user, or some payment.
We really need a "free software library/app store", where people can get compensated for their project in return for giving it under a non-GPLish license by a user who has problems with the GPL. If they have a problem with the GPL, they're obviously profiting of it, and they should expect to give something back (even if it is just a patent pledge or something else which does not cost money out of pocket)
Others just require you to let THEM relicense it, e.g. web2py.
And other projects (mostly those that consider closing source at some point) just refuse contributions.
So did any of them actually make specific complaints (e.g. "I can't link this to with my already-developed proprietary project because your code is GPL. LGPL would work great."), or is it just the usual whiners who complain about anything GPL?
You cannot easily switch licenses because you use other GPLd code. The spirits that you called up will now not let you go.
Well if he uses someone else's GPL licenced code together with his code then his code will have to be GPL aswell, what external GPL code is he using?
If all the code is his then he can relicence it any way he wants, no matter if he has released it as GPL.
It has a few restrictions, it expects that the stack frame for the threads doesn't exceed 4kb, although it could be made more flexible I figured that OS fiber facilities would be more appropriate if heavier weight features were required.
If I understand it correctly, the first call to lthread_create() in the main thread will create a new pthread with a local scheduler. Each call to lthread_create() in that lthread will create local lthreads in that scheduler, so in essence each lthread pool is actually single threaded unless there is a non exclusive or blocking operation you can run lthread_compute_begin()/lthread_compute_end() on. This is opposed to something like Grand Central Dispatch where you can assign "tasks" to the scheduler which will schedule them on an available thread pool.
lthread_compute_begin()/end() moves the lthread into a separate pthread and resumes it there. That pthread is called lthread compute scheduler, its job is to resume lthreads that will take relatively long time to finish a task. lthread compute schedulers are created as needed and they stay alive for 60 secs after which they die of inactivity. If it fails to create a new pthread (max pthreads reached for example) to resume the lthread, then it will get queued in the least busy compute scheduler. When few lthread compute schedulers get created, they act as a pool accepting new lthreads and resuming them, when they cannot handle the load, the pool grows until the pthread limit is reached and jobs will get queued up.
I believe this is close to what GCD does but probably not exactly the same.
Knowing when a long-running task finishes is not easy to guess.
> Cute but only a fool would introduce this complexity and overhead for easing their C programming experience.
Anyway, that's cool. Keep up good work, tebrikler :)
https://github.com/halayli/lthread/tree/master/src/examples
thanks for the heads up. :)
So while adding coroutine support to V8 would probably require some substantial internal rewrites, it wouldn't necessitate changing the language - just add a global Coroutine object with the coroutine-switching functions like create, resume, yield...
If you want to look at the Lua coroutine implementation, start at auxresume (http://www.lua.org/source/5.1/lbaselib.c.html#auxresume) in lbaselib.c, and the functions tagged luaB_ more generally. (In 5.2, they've been moved to their own file, lcorolib.c.)
I'm also guessing that it's also not entirely true that there are no shared resource drawbacks. Whenever lthread moves a heavy computation into a pthread, all synchronization bets are presumably off. If you've got two "CPU intensive" workers that reference the same data structures, then you're still going to need mutexes, right?
On average, yielding ~10 calls deep results in copying ~75 to 100 bytes but it all depends on what has been on the stack. One advantage in lthread is it's easy to take advantage of cores which isn't very natural in IO loops.
Yes you'll need a synchronization mechanism when accessing shared data structures from multiple CPU intensive workers.
I often take addresses of local variables -- if I understood correctly, this deserves a huge warning in the documentation.
I thought I added a warning in the lthread_compute_begin() section but apparently not. I'll go ahead and add it.
Additionally, callbacks have the same amount of overhead but it's not constant because you have to create a side-channel for the state management. That means, instead of a simpler stack for keeping the state, you have to have a periodic stack + a structure or object for all the state even when the callback isn't active.
Node.js is the new fad riding on JavaScript wave. I still don't understand what it brings, when comparing it with more sound alternatives.
http://williamedwardscoder.tumblr.com/post/17112393354/a-sol... might be an interesting distraction ;)
Scroll down to the bottom of the README and look for fibonacci(35) to see how I solve the problem mentioned in the link. The example is a naive HTTP server that computes fibonacci on every request and replies back.
You move it explicitly to its own thread. What would happen if you didn't do that?
My article is applicable to `lthread` too. Its a discussion about what happens to fib(35) or any blocking task running in a multiplexing-tasks-in-a-thread setup really.
Not that there is anything wrong with this approach (I rewrote glib'c memory allocator, which is atrociously broken for modern systems), but you better have a very good explanation for why you did this.
P.S. I won't touch on the fact that a good scheduler will necessarily need to run in kernel-mode, not user-mode. But that's a subject for another discussion.
There might be valid reasons to do so, but since I haven't seen any good explanation I'd just assume this project was coded for lulz or out of technical ignorance.
P.S. "avoids callbacks" and "minimizes complexity" is a red herring; all threaded code has these properties, regardless of how the threading engine is implemented behind the scenes.
Here's a valid explanation, which wasn't explicitly given, although it was hinted at: kernel threads take resources that become significant when you want a very large number of threads (say, one million). The per thread overhead, including user stack, kernel stack and control structures are at a minimum of ~8K. That's 8GB for a million threads before you actually get to do anything useful.
However, lthreads can realistically take as little as 100 bytes per thread, which puts us at a 100MB footprint for the same case. That's a huge difference.
There are tradeoffs, but that's a potentially useful use case which kernel threads do not support (and which, in general, requires async programming, which lthread implements while emulating a thread API).
I get enough of that icky stuff at work.
eps' general concern is that this is entirely a court matter; the spirit of the GPL and sharing is meaningless to the law because at the end of the day there are only so many ways you can type "LIST_INIT(&new_sched->new);" and if a shitty programmer/programmer's company is suing you and has evidence you looked at that line of code that may be enough for a shitty judge to side with them. For similar reasons I don't have a habit of looking at patents (though that's usually because patents, even non-software-patents, are shit and obvious to the layman let alone someone in the field), but I do read (and have contributed to) GPL code.