README 2.5 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768
  1. Copyright (C) 2018 Ariadne Devos
  2. This program is free software: you can redistribute it and/or modify
  3. it under the terms of the GNU General Public License as published by
  4. the Free Software Foundation, either version 3 of the License, or
  5. (at your option) any later version.
  6. This program is distributed in the hope that it will be useful,
  7. but WITHOUT ANY WARRANTY; without even the implied warranty of
  8. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  9. GNU General Public License for more details.
  10. You should have received a copy of the GNU General Public License
  11. along with this program. If not, see <http://www.gnu.org/licenses/>.
  12. # What is lco?
  13. lco, short for lightweight coroutine. It's not *just another* coroutine
  14. library for C, it is intended to make them as lightweight as possible.
  15. Typically, a C thread has a single call stack. When using coroutines, however,
  16. one can create a new stacks to switch to, and switch back later - or not at
  17. all.
  18. What makes lco different, or, what will make lco different (as we aren't there
  19. yet), is that it performs a statical analysis of the code to determine an upper
  20. bound on how much stack the program will need. So you know aforehand how much
  21. memory your coroutine will consume (not counting dynamic memory allocation
  22. made by the code).
  23. In principle, lco is architecture-independent. It is not OS-independent; I do
  24. not expect it to be fully ported to Microsoft Windows (syscalls might be
  25. difficult).
  26. Dynamical linking is not expected to become a problem.
  27. # How to use?
  28. Edit the Makefile to change ARCH into your architecture, then do 'make test'.
  29. There are now three files of interest: the object files lco-x86-64.o and lco.o
  30. and a header lco.h. As of now, lco.h is the documentation.
  31. # Why all this effort to minimise stack sizes?
  32. If less memory is reserved for the program, the computer needs less RAM and can
  33. therefore be less costly. But we can't just choose a stack size and stick to it,
  34. as some programs need much more than others. We have to perform some analysis,
  35. preferably in an automated fashion.
  36. # Supported platforms
  37. x86-64 Linux (doesn't require redzone)
  38. The BSDs shouldn't require much change.
  39. Non-linux systems might not like the way the stack pointer is manipulated.
  40. # Support
  41. If there is some reason for contacting lco's maintainer, see process/contact.md.
  42. For a list of known bugs, see process/bugs.md.
  43. lco will have a website at
  44. <https://ipfs.io/ipns/QmXikbcdm5uhLEiUzhqvgRP8QQvJ5WX9GwFqti849wKrLw/>.
  45. lco has a public git repository at
  46. <https://notabug.org/ariadne/lco>.