Skip to content
Permalink
Browse files
initial commit
  • Loading branch information
dshatrov committed Oct 18, 2015
0 parents commit 8cf6eafd846aba57963dae056f043f523b905ef4
Showing 781 changed files with 194,478 additions and 0 deletions.
@@ -0,0 +1,2 @@
Dmitry Shatrov <shatrov@gmail.com>

661 COPYING

Large diffs are not rendered by default.

770 Makefile

Large diffs are not rendered by default.

@@ -0,0 +1,30 @@
#ifndef LIBMARY__LIBMARY_CONFIG__H__
#define LIBMARY__LIBMARY_CONFIG__H__

#undef LIBMARY_GLIB
#define LIBMARY_PTHREAD 1

#define LIBMARY_MT_SAFE 1

#define LIBMARY_ENABLE_EPOLL 1
#undef LIBMARY_ENABLE_KQUEUE

#undef LIBMARY_WIN32_IOCP
#undef LIBMARY_USE_SELECT
#undef LIBMARY_USE_POLL

#define LIBMARY_PLATFORM_DEFAULT 1
#define LIBMARY_PLATFORM_ANDROID 1
#undef LIBMARY_PLATFORM_FREEBSD
#undef LIBMARY_PLATFORM_MACOSX
#undef LIBMARY_PLATFORM_WIN32
#undef LIBMARY_PLATFORM_CYGWIN

#undef LIBMARY_ENABLE_MWRITEV

#undef LIBMARY_WIN32_SECURE_CRT

#define LIBMARY_NO_EXCEPTIONS 1

#endif /* LIBMARY__LIBMARY_CONFIG__H__ */

@@ -0,0 +1,10 @@
#ifndef LIBMOMENT__LIBMOMENT_CONFIG__H__
#define LIBMOMENT__LIBMOMENT_CONFIG__H__

#undef MOMENT_GSTREAMER
#undef MOMENT_NETTLE
#undef MOMENT_CTEMPLATE
#undef MOMENT_GPERFTOOLS

#endif /* LIBMOMENT__LIBMOMENT_CONFIG__H__ */

@@ -0,0 +1,30 @@
#ifndef LIBMARY__LIBMARY_CONFIG__H__
#define LIBMARY__LIBMARY_CONFIG__H__

#undef LIBMARY_GLIB
#define LIBMARY_PTHREAD 1

#define LIBMARY_MT_SAFE 1

#define LIBMARY_ENABLE_EPOLL 1
#undef LIBMARY_ENABLE_KQUEUE

#undef LIBMARY_WIN32_IOCP
#undef LIBMARY_USE_SELECT
#undef LIBMARY_USE_POLL

#define LIBMARY_PLATFORM_DEFAULT 1
#undef LIBMARY_PLATFORM_ANDROID
#undef LIBMARY_PLATFORM_FREEBSD
#undef LIBMARY_PLATFORM_MACOSX
#undef LIBMARY_PLATFORM_WIN32
#undef LIBMARY_PLATFORM_CYGWIN

#undef LIBMARY_ENABLE_MWRITEV

#undef LIBMARY_WIN32_SECURE_CRT

#define LIBMARY_NO_EXCEPTIONS 1

#endif /* LIBMARY__LIBMARY_CONFIG__H__ */

@@ -0,0 +1,10 @@
#ifndef LIBMOMENT__LIBMOMENT_CONFIG__H__
#define LIBMOMENT__LIBMOMENT_CONFIG__H__

#undef MOMENT_GSTREAMER
#undef MOMENT_NETTLE
#undef MOMENT_CTEMPLATE
#undef MOMENT_GPERFTOOLS

#endif /* LIBMOMENT__LIBMOMENT_CONFIG__H__ */

@@ -0,0 +1,29 @@
#ifndef LIBMARY__LIBMARY_CONFIG__H__
#define LIBMARY__LIBMARY_CONFIG__H__

#undef LIBMARY_GLIB
#define LIBMARY_PTHREAD 1

#define LIBMARY_MT_SAFE 1

#undef LIBMARY_ENABLE_EPOLL
#define LIBMARY_ENABLE_KQUEUE 1

#undef LIBMARY_WIN32_IOCP
#undef LIBMARY_USE_SELECT
#undef LIBMARY_USE_POLL

#undef LIBMARY_PLATFORM_DEFAULT
#undef LIBMARY_PLATFORM_FREEBSD
#define LIBMARY_PLATFORM_MACOSX 1
#undef LIBMARY_PLATFORM_WIN32
#undef LIBMARY_PLATFORM_CYGWIN

#undef LIBMARY_ENABLE_MWRITEV

#undef LIBMARY_WIN32_SECURE_CRT

#define LIBMARY_NO_EXCEPTIONS 1

#endif /* LIBMARY__LIBMARY_CONFIG__H__ */

@@ -0,0 +1,10 @@
#ifndef LIBMOMENT__LIBMOMENT_CONFIG__H__
#define LIBMOMENT__LIBMOMENT_CONFIG__H__

#undef MOMENT_GSTREAMER
#undef MOMENT_NETTLE
#undef MOMENT_CTEMPLATE
#undef MOMENT_GPERFTOOLS

#endif /* LIBMOMENT__LIBMOMENT_CONFIG__H__ */

@@ -0,0 +1,5 @@
LibMary is a portability, multithreading, and basic utility library for
high-performance network servers written in C++.

Moment Video Server uses LibMary as its core library.

@@ -0,0 +1,42 @@
Подробный разбор нововведений в стандарте C++0x, касающихся многопоточности.

Разбираю разделы 1.10, 29 и 30 предварительной версии нового стандарта C++.

1. Разбор раздела 1.10, "Multi-threaded execution and data races".

* thread == thread of execution;
* гарантируется, что незаблокированные процессы в некоторый момент получат
управление независимо от состояния заблокированных процессов;
* expression evaluations conflict: modify -> (memory location) -> access;
* ряд атомарных операций и операции над мьютексами являются опреациями
синхронизации. Операции синхронизации по типу делятся на consume, aquire,
release и одновременные "aquire+release". Операция синхронизации без
ассоциированного участка памяти - это fence. Fence может быть aquire, release
и (aquire + release).
В добавление к этому существуют relaxed атомарные операции, не являющиеся
операциями синхронизации, и атомарные операции read-modify-write;
* Существует modification order атомарного объекта. Modification order двух
различных атомарных объектов не связаны между собой;
* release sequence в результате операции release (A): подпоследовательность
модификаций в modification order, в которой A - первая операция, и каждая
последующая операция:
* выполнена тем же потоком, который выполнял A;
или
* является атомарной операцией read-modify-write;
* даётся определение A carries a dependency to B, достаточно очевидное;
* atomic store-release - это запись в atomic, совмещённая с семантикой release
мьютекса. Аналогично - для load-acquire;
* [...]

Пример в самом низу страницы: http://www.hpl.hp.com/research/linux/atomic_ops/example.php4
Мне кажется, что использование "!is_initialized" без AO_ некорректно.
Но я всё ещё не могу судить об этом сознательно. Нужно понять, чем
определяется корректность.
- там стоит pthread_mutex_lock, в нём дело.

Статьи Herb Sutter на drdobbs.com - по теме.

Relacy race detector - иметь в виду (header-only, ~11K строк).

(Прервал анализ, выяснив, что с реализациями C++0x atomic пока плохо).

@@ -0,0 +1,40 @@
Ввод/вывод через IOCP.

Нужно определиться, как гарантировать доступность OVERLAPPED и буферов
при асинхронном I/O под Windows.

Интерес представляет момент удаления объектов Connection, Sender, Receiver
и момент удаления IocpPollGroup (далее - IOCP).

Можно считать, что Connection, Sender и Receiver удаляются только одновременно.

Connection нужно удалять обязательно, т к CloseHandle используется для
cancellation. Поэтому Overlapped выносится в отдельный вспомогательный объект.

Моментов для удаления у Overlapped два: когда удаляется Connection без
незавершённых операций и когда завершается последняя операция.

Обобщённый вариант для Overlapped - подсчёт ссылок. Новая операция - новая
ссылка, плюс одна ссылка у Connection.

read() -> pending -> ref()
inputComplete -> unref()
В этом случае unref должна делать IOCP-группа. Т е это unref
на каждое уведомление.

Избавиться от синхронизации можно через выделенный lock: вынести mutex
Sender'а и Receiver'а в структуру, связанную с Overlapped. Потребуется
разделение read и write операций, два мьютекса. Станет невозможна
независимая проверка завершения операций чтения и записи.
Правильное решение по синхронизации - отправлять данные только из
потока, к которому привязано соединение.

Следовательно, использую OverlappedBlock и счётчик ссылок на него.

А если IOCP разрушается первой? Уведомления не будут получены. В этом случае
нет способа отличить ссылки от незавершенных операций и ссылку от неразрушенного
Connection.
- удалять IOCP в собственном потоке так, чтобы не требовалась
дополнительная синхронизация. А сейчас просто допускать потерю
ссылок на OverlappedBlock.

Empty file.
@@ -0,0 +1,54 @@
libMary is coded in such a way that it can serve as a prototype for the core
library written in Mt programming language. Albeit libMary is written in C++,
it uses only the subset of C/C++ features which Mt is about to support.

This document describes C++ constructs which are meant to map to equivalent
Mt constructs. It also defines the subset of C++ which is allowed to be used
in Mt-like programs.

1. All plain C constructs are allowed. Unsafe operations (pointer ariphmetic)
must be placed within "mt_unsafe {}" block.

2. Only language-class objects (the ones defininf C++ to Mt pseudo mapping)
are allowed to use overloading of names and operators.

3. Only language-class objects are allowed to use multiple inheritance.
Virtual base classes are explicitly forbidden.
Language constructs for interfaces are discussed separately.

4. Safe memory operations are operations on Memory objects.

5. Generic representation for callbacks (closures) is class Callback.

6. Annotations are represented as tokens with "mt_" prefix: mt_annotation
mt_mutex, etc.

7. Although the language is named Mt, its namespace is shortly named "M" for
convenience.

8. There's two base Referenced classes: one for synchronous objects and another
one for asynchronous objects: Object and AsyncObject. Everything that
supports references supports weak references as well.

9. C++ exceptions are not allowed. RTTI is not allowed and should be disabled
at compile-time.

10. C++ standard library is not allowed at all (except for numeric limits).

11. Only a small subset of the standard C library is allowed to be used. There
is a defined set of symbols which can be used.

12. Only default non-failing constructors are allowed.

13. Templates are allowed. Partial template specializations are forbidden..

14. C++ references (&) are allowed only within implementations of language-class
objects.

15. Destructors must be short and to the point. Keep in mind that there are
deletion queues which are protected from nested processing.

LibMary serves as a standard library and is an image of Mt library. It is
supposed to be Rich, i.e. it should cover most of the needs of domain-specific
applications (server applications).

@@ -0,0 +1,16 @@
Сборка на FreeBSD.

Нужен компилятор не младше gcc 4.3

pkg_add -r gcc46
pkg_add -r libtool
pkg_add -r autotools
pkg_add -r pkg-config

pkg_add -r gstreamer-ffmpeg
pkg_add -r gstreamer-plugins-speex

export CC=/usr/local/bin/gcc46
export CXX=/usr/local/bin/g++46
./configure --with-select

@@ -0,0 +1,19 @@
От применения исключений C++ отказываюсь. Причины:
* Сложно контролировать поток исполнения;
* Переусложняется управление примитивами синхронизации в многопоточных
программах;
* Исключения не следует использовать в качестве кодов ошибок, но тогда
зачем вообще они нужны?

Взамен libmary предлагает расширенный механизм сохранения информации об ошибках
наподобие errno.

Работа с исключениями производится с помощью макросов:
* exc_throw - установка новой ошибки;
* exc_push - установка ошибки, связанной с предыдущей (предыдущая ошибка
считается причиной новой);
* exc_none - сброс стека ошибок.

Каждое исключение - это объект типа Exception с виртуальным методом toString().
С объектами исключений можно использовать механизм RTTI.

0 comments on commit 8cf6eaf

Please sign in to comment.