Yes it is not just a problem with ring buffers ,
First what I'm doing , I'm building an IPC layer , and your comment on the captalk/Capros list whether to have Asynchronous IPC and No Blocking was quite thought provoking in terms of pushing back what is possible , what the system/runtime can do for the app and resource management and I have lots of things I want to try ( eg how to handle back pressure more intelligently or even transparently , growing and collapsing queues/ring buffers etc ). In term of Bitc the problem here all just relate do dynamic sized arrays - Arrays of arbitrary size but the size is contained in a separate field ( eg Dependent types) - Alignment to emphasize data of a sub member on 16 byte boundary important so mem_cpy doesn't waste time for SSE - There may be no data.so 0 length array with no storage of type ... - Casting a struct to byte data and visa versa. ( IMHO this and the alignment is the only real pointer stuff that is needed) In terms of safety you are correct in that the system very carefully handles safety here though I think a custom DSL for low level messages is a bit too awkward ( IMHO it didn't work for Singularity but was a nice idea) . I originally was going to use C# with unsafe but the logic on how the Aysnc apps work and runtime is what I'm really interested in and a functional style language for the run time is a better fit . Dependent type and more importantly casting an address to a structure and getting an address ( with the appropriate fixing for GC cases later) are important for interop ( though for all I know it may be possible ) . Since BitC is targeted at low level development interfacing with C is probably the biggest obstacle to early adoption and that means lots of crap like AllocSysstring in windows etc , while not as nice as language design/features I'd say it's probably more important. . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
