сообщить из DLL о наличии нового тика другой программе - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
так это ведь периодически проверять, не появился ли новый message.
Мне нужно именно из вне вызвать мою ява методу, сообщить что есть новые данные.
Думаю, что сокеты- то, что нужно.
А для односторонней передачи хватит и blocking sockets
(клиент в blocking read- а сервер при необходимости пишет).
Думаю, что сокеты- то, что нужно.
А для односторонней передачи хватит и blocking sockets
(клиент в blocking read- а сервер при необходимости пишет).
Тогда уж лучше NamedPipes.
А чем лучше? Я вот тут для межпроцессного взаимодействия полирую асинхронные сокеты...
быстрее и меньшая нагрузка на систему при больших объёмах данных. Если конечно только для синхры и текущих тиков - разница будет незаметной.
It is also important to clarify if you are talking about local pipes or network pipes. If the server application is running locally on the computer running an instance of Microsoft® SQL Server™ 2000, the local Named Pipes protocol is an option. Local named pipes runs in kernel mode and is extremely fast.
http://msdn.microsoft.com/en-us/library/aa178138(SQL.80).aspx
JavaDev, спасибо. Интересно.
.
В моей задаче будет передаваться имя файла и его новая длина.
Сами данные- в файле. Точнее- в оперативе операционки в кэше.
.
А сокеты потом можно будет переиспользовать для чего-то интересного ;-).
JavaDev, спасибо. Интересно.
.
В моей задаче будет передаваться имя файла и его новая длина.
Сами данные- в файле. Точнее- в оперативе операционки в кэше.
.
А сокеты потом можно будет переиспользовать для чего-то интересного ;-).
Для маппинга сделал просто офигенный враппер! :-)
.
Весь код пишется примерно так:
.
Mapping::File file("data.bin");
file.Resize(100 * Utils::MBYTE);
file.ReadWrite();
Mapping::View view = file.CreateView(HstHeaderSize, 0,0,0,0, sizeof(RateInfo));
while(!view.IsEof())
{
view.At<RateInfo>() = ...;
view.Next();
}
.
Сразу автоматом на файл вешается Sparse аттрибут, резервируется размер,
прокрутка страниц проводится автоматом и т.д.
.
Потом задумался над вопросами:
- для того, чтобы писать в файл, нужно резервировать под аттрибутом sparse солидный размер данных (те же 100 мегабайт)
причем тупенькие архиваторы не знают о sparse файлах... и будут читать все 100 Мб.
- для продолжения работы с таким файлом надо анализировать структуру файла на диске (фиг с ним, сделал)
- когда дисковое хранилище проанализировано, приходится рыться в последней странице (64К) и искать там где последний
пустой элемент (еще раз фиг с ним- опять сделал)
- выставление конца файла означает прекращение записи с использованием маппинга.
.
Ну и зачем это все надо?
То, что круто- да. Может быть, побыстрее. Может быть, сильно быстрее.
... А оно- это побыстрее- надо? Или заниматься преждевременной оптимизацией?
Для тестового задания такую штуку сделать можно. Если приперло по производительности- то можно.
Если заплатили за работу с маппингом и тестирование класса маппинга- можно (клиент сказал хочу маппинг и все).
А зачем ее делать "просто так"?
.
Выкидываем весь код, пусть даже оттестированный и рабочий, который работает
с маппингом- и программа сразу упрощается.
.
Для чтения файла целиком у нас штрафов практически нет.
А то, что мы будем дочитывать с конца- там выигрыш смешной.
Не самый лёгкий путь прошёл ... :)
Раньше было просто лень разбираться- а теперь могу на уровне эксперта ответить,
почему такой хороший маппинг- и не нужен :-). В некоторых случаях он неплох.
.
P.S.:
Еще забыл добавить, что при чтении данных нужно зачастую уничтожать текущее
отображение и маппирование, чтобы пересоздать с новым размером.
Ну уж 4 вызова функций WinAPI + оно внутри себя будет делать пере-отображеине
страниц памяти- это явно хуже чем один ReadFile.