1. Write a book (or a rant, for that matter) 2. Put it on the internet, somewhere it is likely to be copied illegally 3. Now go out on the streets, use a megaphone, and start proclaiming you're an author and you don't take it anymore. 4. Repeat every Saturday morning in a shopping mall. 5. People in your neighborhood will eventually hate copyright. 6. ? 7. Profit.
Thanks for all the explanations. Your approach to multi-threading looks very interesting. I'm still wondering if you can always guarantee that fibers will never take more time than you give them, but I suppose you have all those cases covered.
Further, I'm wondering, since your project is so large, if you considered splitting it up into smaller projects. For example, your distributed database could possibly be useful to the C++ community as well. And that fiber/CPS approach could be useful in other (non-web-related) contexts too (why don't we have that GCD system in Linux yet, for example?):)
Finally, all these technical explanations you are giving here should really be on your website, I think (in more detail than the white-paper). Attracting the attention of skilled people to your project requires this level of detail, especially since your project has such a great impact on the overall way of working (and thinking) of your developers.
And while you're at it:) you could include information on how you handle garbage collection (are you using a concurrent collector, or one that occasionally halts execution of the program), and on how your distributed database works. And perhaps you could include some benchmarks (a la the great programming language shootout) to make it all really convincing.
If only they let the bytecode access directly the underlying opengl graphics primitives, we could implement our own rendering engines in this bytecode language and be done with html5 compatibility problems forever... (of course assuming that other browser vendors will use the same bytecode).
Even if the fibers are small, they may invoke kernel calls which take a long time to complete (for example a large I/O operation). How do you ensure that other fibers can continue their work in such cases?
Further, the smaller your fibers get, the more overhead you introduce for context-switching, right? Because I can imagine that after execution of each fiber you need to do some scheduling (even if the current fiber remains active). Is this context-switching faster than the kernel can do it?
Finally, I'm interested in what makes scheduling for the web such a specialized task, but that may be related to the previous question.
We have lightweight threads can be preempted any time they are not in (Opa) kernel mode, and rely on asynchronous I/O (epoll/kqueue/completion ports) to achieve non-blocking I/O. Does this answer your question?
Could you explain this a little further? In my understanding, the epoll based approaches are all synchronous, non-preemptive. That is, in such a method you wait in an event-loop for events, and when an event arrives, you perform some action, effectively keeping other events in the queue. This means that if one event triggers a lengthy computation, then other users of the system may experience non-responsiveness.
Hmmm, fibers may not be the right tool for making low-latency (highly responsive) multi-user applications. The problem is that when one fiber is doing a lengthy task, the other fibers are sleeping until the first fiber yields. That's why the popular web-servers go through all the trouble of spawning multiple threads instead of just using an event-loop approach (using select, epoll and kqueue). Sure, you will not have any additional context-switching overhead that way, but today low-latency is what counts.
How does opa handle multiple threads of execution? Any decent server nowadays just needs to have multiple threads of execution, sometimes even thousands of them to work in a non-blocking way. Opa seems to be "non-blocking" (I read from the tutorial), but you have non-blocking and non-blocking... One version simply uses one thread and an event-loop (aka non-preemptive multitasking). This is not truly non-blocking, as large I/O operations in one task still prevent other tasks from working. And does opa allow us to control the priority of different threads?
Also, does Opa have support for fallback to the underlying systems (javascript/databases etc.)? If something is not supported by Opa (very likely in the beginning), I sure want to be able to fix it myself without having to understand all the opa internals.
So they're targeting javascript. This is going to be, uhm, not the most efficient approach.
What should happen, imho, is for W3C to develop a (non-garbage collected, as in no garbage collection) low level language, which can serve as a platform for other languages, like this one. Current compiler and virtualization technology can easily and efficiently translate such low level language into something native. And as a result, we could have a much richer web environment, and we'd not be dependent on that one strange little language we've been having to put up with. Open up the web-computing environment, and open-source languages could proliferate here.
Slashdot Mirror
I'm not sure if it is really aggression. It is probably just the new way of doing business.
Don't forget that Samsung also provides Apple with components.
Perhaps, as long as they don't try to cross any country borders.
If webcrawling had been opt-in, Google would not have existed now.
Nah, that line has already been copyrighted.
Simple solution:
1. Write a book (or a rant, for that matter)
2. Put it on the internet, somewhere it is likely to be copied illegally
3. Now go out on the streets, use a megaphone, and start proclaiming you're an author and you don't take it anymore.
4. Repeat every Saturday morning in a shopping mall.
5. People in your neighborhood will eventually hate copyright.
6. ?
7. Profit.
Not long down the road, all those Filipino maids in the rich palazzos, palaces, and chateaus will be replaced with American maids.
Let's replace them by lawyers, as we have too many of them anyway.
they pulled the sales equivalent of a man in the middle attack.
Almost 15,000 people bought the apps.
There. Making stupid apps for iOS will not make you a millionaire.
...unless you submit yourself to an INDEPENDENT audit you will be revoked from our default trusted root certs
In the case of Diginotar, Price Waterhouse Coopers was doing the audits.
And how about making a 3D memory chip? If you have one for backup purposes, you don't need the speed, and thus will not dissipate that much heat.
That's certainly not a company I'd entrust my data to.
Hi Seferino,
Thanks for all the explanations. Your approach to multi-threading looks very interesting. I'm still wondering if you can always guarantee that fibers will never take more time than you give them, but I suppose you have all those cases covered.
Further, I'm wondering, since your project is so large, if you considered splitting it up into smaller projects. For example, your distributed database could possibly be useful to the C++ community as well. And that fiber/CPS approach could be useful in other (non-web-related) contexts too (why don't we have that GCD system in Linux yet, for example?) :)
Finally, all these technical explanations you are giving here should really be on your website, I think (in more detail than the white-paper). Attracting the attention of skilled people to your project requires this level of detail, especially since your project has such a great impact on the overall way of working (and thinking) of your developers.
And while you're at it :) you could include information on how you handle garbage collection (are you using a concurrent collector, or one that occasionally halts execution of the program), and on how your distributed database works. And perhaps you could include some benchmarks (a la the great programming language shootout) to make it all really convincing.
Bests,
StripedCow
If only slashdot articles were written in this style in the first place, we wouldn't have to RTFA.
Yep, Google is just one big mechanical turk.
If only they let the bytecode access directly the underlying opengl graphics primitives, we could implement our own rendering engines in this bytecode language and be done with html5 compatibility problems forever... (of course assuming that other browser vendors will use the same bytecode).
Even if the fibers are small, they may invoke kernel calls which take a long time to complete (for example a large I/O operation). How do you ensure that other fibers can continue their work in such cases?
Further, the smaller your fibers get, the more overhead you introduce for context-switching, right? Because I can imagine that after execution of each fiber you need to do some scheduling (even if the current fiber remains active). Is this context-switching faster than the kernel can do it?
Finally, I'm interested in what makes scheduling for the web such a specialized task, but that may be related to the previous question.
We have lightweight threads can be preempted any time they are not in (Opa) kernel mode, and rely on asynchronous I/O (epoll/kqueue/completion ports) to achieve non-blocking I/O. Does this answer your question?
Could you explain this a little further? In my understanding, the epoll based approaches are all synchronous, non-preemptive. That is, in such a method you wait in an event-loop for events, and when an event arrives, you perform some action, effectively keeping other events in the queue. This means that if one event triggers a lengthy computation, then other users of the system may experience non-responsiveness.
Hmmm, fibers may not be the right tool for making low-latency (highly responsive) multi-user applications. The problem is that when one fiber is doing a lengthy task, the other fibers are sleeping until the first fiber yields. That's why the popular web-servers go through all the trouble of spawning multiple threads instead of just using an event-loop approach (using select, epoll and kqueue). Sure, you will not have any additional context-switching overhead that way, but today low-latency is what counts.
Or am I missing something?
How does opa handle multiple threads of execution? Any decent server nowadays just needs to have multiple threads of execution, sometimes even thousands of them to work in a non-blocking way. Opa seems to be "non-blocking" (I read from the tutorial), but you have non-blocking and non-blocking... One version simply uses one thread and an event-loop (aka non-preemptive multitasking). This is not truly non-blocking, as large I/O operations in one task still prevent other tasks from working. And does opa allow us to control the priority of different threads?
Also, does Opa have support for fallback to the underlying systems (javascript/databases etc.)? If something is not supported by Opa (very likely in the beginning), I sure want to be able to fix it myself without having to understand all the opa internals.
Grandfather isn't even the right translation. "Grampa" would come closer. LOL
That's good, but then it still is an important part, since building web-apps nowadays is getting more and more important.
Well, I guess we'll first need to have a bunch of languages targeting javascript, before W3C sees the light. Sigh.
So they're targeting javascript. This is going to be, uhm, not the most efficient approach.
What should happen, imho, is for W3C to develop a (non-garbage collected, as in no garbage collection) low level language, which can serve as a platform for other languages, like this one. Current compiler and virtualization technology can easily and efficiently translate such low level language into something native. And as a result, we could have a much richer web environment, and we'd not be dependent on that one strange little language we've been having to put up with. Open up the web-computing environment, and open-source languages could proliferate here.
How about the transparent plastic "window" in which you could put the insert?
As long as these printers can't produce a real-looking dvd/blueray case, including insert, I'm not impressed.
Or it just might be that hot sulfur conditions might be a good way to start life rolling
Just like carbon compounds are good catalysts for silicon-based life.