Am 11.11.2013 um 14:22 schrieb andy pugh <[email protected]>: > On 10 November 2013 08:14, Michael Haberler <[email protected]> wrote: >> I've written up an initial requirements document for the future LinuxCNC >> middleware which is to replace NML/RCS. > > I am curious what you think is wrong with NML/RCS. I am not arguing > that there isn't anything wrong with, it I am just wondering what the > "issues list" is.
legit question. A few reasons: - serialisation: unsuited for RT usage (C++ objects - transcoding required at RT boundary, so uninterpreted end2end message contents not possible; see also verious warts and workarounds for error messages out of RT) - arbitrary limits: 'buffer size' (nowadays 16k or so, config time) - manual serialisation - defining a new message is absurdly complex and error prone - no way to support optional or repeated fields in a message, and hence detect presence/repeat count on receiving end - no way to support arbitrary length fields in a message - no support for NULL values (i.e. not 'zero', but 'non-existent') - no introspection support *) - no versioning support/message extensions where old code at least understands the base part - all manual language bindings - no complete EMC NML bindings available even today for say Python because the effort is absurd - IDL support vanished in the mists of history - transport: rather fuzzy and low level semantics - the 'M' in 'NML' stands for 'message' which is usually understood to be a record which is subject to queued transactional interaction, but what the model really is is a named shared memory buffer (except for the error message queue), with all sorts of funny effects if writers dont behave - no transport abstraction to interact with RT (besides serialisation limitations mentioned above) - no abstraction to support message-based interaction between RT components - no support for common interaction patterns like remote procedure call or publish/subscribe **) - no routing support in presence of multiple consumers/multiple producers - no clear concept of how to indicate 'message consumed' - see assorted problems with serial_number - consumption semantics: no way to publish a message to more than one subscriber - first consumer wins, others dont see the message - network capability: decayed to the state that we dont seem to know if it actually works anymore - unmaintained and unused outside linuxCNC - code base readability: no polite comment I could think of - low level of abstraction - using code repeats long wads of incantations, for instance buffer attach at startup - polling is the only way to detect progress - no blocking waits, no callbacks, no reactor pattern - no integration in event loops like gevent, qt, libev, poll(2), eventfd etc, making integration into UI's yet another polling exercise - abysmal performance due to fixed polling cycles and associated overhead shortening the same if more punch is needed - see for instance the 'emctaskeager' variable in task for a related hackaround - no support for encryption and authentication - no support for peer autodiscovery - nml config, linuxcncserver - not sure what value this adds, other stacks work perfectly fine without any of these It is so bad I think 'fixing up' NML is hopeless - it's beyond repair. -m *) to see what this means in practice: see https://github.com/shramov/json2pb which does introspection-based translation of protobuf messages to/from JSON in a mere 270 lines of C++, including strong type checking and schema validation. Completely generic, not tied to any particular protobuf message format, and agnostic of same. No way to do this in NML except manually converting every single message and every single field in it. Not me ;) **) see for example the pattern spectrum available in http://zguide.zeromq.org/page:all#toc32, nanomsg: http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html, or nitro: http://gonitro.io/ > >> >> http://static.mah.priv.at/public/wip/html/wip/requirements.html#_configuration_requirements > > I don't see anything wrong with the requirements, but then I am not > sure I know enough about the issues. (see my first question) > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
