While linear types enforce the desired properties, the fact that they can't > handle fork/join behavior turns out to be a pretty significant impediment. > One alternative would have been borrowed pointers, but that would have > required significant further changes to the compiler, which *may* have > been beyond the level of developer resource that Singularity had available > (I don't know). >
Winrt uses a borrowed pointers here you cast the object as an IWeakReference and it can become null at any point .. this avoids reference counting but you need to handle the null ref exception - it can become null . Is the nul ref exception that bad anyway ? Its not important to write correct algorithms that handle this going to null as the case when this happens it means the server has crashed or pulled your data .. so you need to stop and if you can get back to some decent state your doing better than we can do on most OS now. > > Separately, there are cases, for example, where we would like to implement > a stream of some sort between processes. That was hard. > Why wouldnt the stream be in the process working on non ref scalar data ( byte[] ) in the shared heap . > > > Perhaps ARC would have worked, but ARC would mean giving up one of the > motivations for linear types: isolation. If exactly one process can hold a > reference to something in the shared heap, then we know that no action by > any *other* process can alter the data in that object. That's a > surprisingly important guarantee in some cases. > > I think we need to be careful about passing judgement on solutions before > we have a clear understanding of the problem they were trying to solve. > Singularity may or may not have been solving the right problem (it's not > obvious to me one way or the other). Given the problem they said they were > trying to solve, linear types were a pretty exact fit. > It wasn't this i was critical about - i dont think that was a heavy design that offered poor performance , the "heavyness" was the whole type checking for communication between processes. eg specify the IDL file in the metadata , then all the type checks for versions that are compatibe etc .. re the IPC data transfer mechanism itself type safety between processes is terribly ambitious .. most times you move lots of data and single copy through the whole stack would be great even just for scalar data , so what is wrong with a shared byte[] and string[] heap . For objects it gets harder but the current method of serializing is not bad .. you can also create immutable types .. with only the creator owning it .. Ok so you have immutable messages. buffers ( byte[] ) and strings thats 90% of requirements and better than we do today. Now you can push it and say you want an Oct tree in a 3D API which an app communicate with .. Actually i dont mind a scheme where pointers can go null when things go badly wrong as its worse in shared memory situations. > >> Regarding ARC didnt Singularity have an ARC GC which you can state in >> MetaData ? DIdnt they test this ( the borrowed pointers is a further >> optimization ) ? Arc is certainly attractive for system objects .. >> > > I don't know about the "ARC in metadata" question. Yes, ARC *is* attractive > for system objects, except that it doesn't address the issue of isolation. > Each Sing app had a metadata file and you could tell it what GC to use , one was ARC but this is not system objects. > > >> Note winrt uses ARC and weak references like borrowed pointers and it >> was certainly influenced by singularity. ( You take a weak reference and >> use it for reads) .. >> > > I'm not aware of any borrowing from Singularity that occurred in WinRT. > Are you speculating, or can you point to something that confirms this? > Lets say a guess.. Management often tries to get something out of failed / R&D projects i see quite a lot ideas which were explored in Sing ( or modern alternatives for things that were pushed hard in sing) in Winrt , by influenced i also mean things that were difficult or too far that were avoided .. - IPC uses ref counting and cast to Weak reference which means they can go null. Its worth noting the gcnew keyword is reserved so in future they may support a gc for managing the com objects themselves.. Also the com object may use a GC internally eg a C# component uses inheritance and GC but objects that are exposed outside the component are marked sealed so no inheritance and tracked between components via ref counting. I vagualy remember a dev posting that the reason for this was ref counting is supported by all code native , managed etc . ( of topic but I tested these components a C++ and a C# doing virtual calls across components and the C# one was noticably faster due to polymorphic inline caches ) - reboot of com for small components which ae like assemblies but also support native with metadata. ( though unlike sing there is only very limited IPC ..) - capabilties (simpler than singularities sec model which was hard for me to follow but sing had some work on caps ) - ref counted system objects ( the winrt components) after microsoft string of failures to get GC working . - No shared dlls - strongly typed communication between components via metadata. ( note components cant communicate to other proceses you have to go via tcp/ip) Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
