jtatton
Re:The Concurnas Programming Language
on Wednesday May 27, 2020 @07:37PM (#23331543)
Hi thanks for raising this. I will add more details around benchmarking and the points you have raised to the documentation. Some answers for now:
- One may use the `shared` keyword in order to override the default copying semantic of Concurnas for mutable data. In this way one may spawn 10 isolates operating on an array without copying it 10 times. Of course this may introduce non deterministic behavior if they overlap in terms of how data is proceed in that array, so care must be applied. Also, a class may be marked as being shared, again suppressing copying, this is handy if if one is importing already thread safe Java code.
- In terms of off heap support all classes are augmented with runtime generated serializers and deserializers (https://concurnas.com/docs/offHeap.html#serialization-of-obj...). Off heap memory support is an area where I'd like to improve Concurnas some more. I think that some form of value type support would be beneficial here. The goal being for it to be possible for one to implement an efficient RDBMS or NoSQL system in Concurnas itself.
- For remote computing, yes there is caching of code to avoid retransmission (the documentation could be better regarding this, I will update the following in due course: https://concurnas.com/docs/distComp.html#request-dependencie...)
- The point about work unit size for remote computing is interesting, I wonder if there is a framework/general method for solving this sort of problem (feels like a solved problem).
Re:The Concurnas Programming Language
on Wednesday May 27, 2020 @06:26PM (#23330875)
Hi thanks for raising this, as far as single machine computation is concerned, Concurnas supports unchecked exceptions. Also, exceptions occurring within the context of isolates are either handled by a (overridable) error handler (which defaults to output to stderr) or more commonly, set to the returned ref from the isolate execution. Then when that ref is accessed the exception is then thrown by the accessor(s) and can be handled as appropriate.
As far as distributed computing is concerned, here the error landscape is much larger than with single machine computation (network disconnections etc). The distributed computing component of Concurnas allows one to define custom error handlers which can deal with errors occurring specifically from distributed computing, and there are a couple of pre-defined error handlers which can be used to assist here (fail on first incident and retry up to x times): https://concurnas.com/docs/distComp.html#common-error-handli...
The documentation about distributed computing (and distributed error handling in particular) could be better written. I will look to make that a priority now that you've raised this point.