|
MononcQc posted:Just use isolated processes and talk by message passing "it's too hard to make objects interoperate in one process, let's add a serialization requirement and distributed GC to the mix"
|
#
?
Feb 16, 2015 19:49
|
|
|
|
| # ? Jun 11, 2024 00:46 |
|
|
MononcQc posted:Just use isolated processes and talk by message passing The aeron messaging system pretty much promotes this, have more cores spin waiting just because 
|
|
#
?
Feb 16, 2015 19:52
|
|
|
MononcQc posted:Just use isolated processes and talk by message passing ur right lets come up w/ a standard model for it. a standard object model... for these components...
|
|
#
?
Feb 16, 2015 20:24
|
|
|
Subjunctive posted:"it's too hard to make objects interoperate in one process, let's add a serialization requirement and distributed GC to the mix" isolated processes would mean you don't ever touch distributed GC. lol if your PL of choice doesn't have a way to serialize all of its types.
|
|
#
?
Feb 16, 2015 20:25
|
|
|
MononcQc posted:isolated processes would mean you don't ever touch distributed GC. lol if your PL of choice doesn't have a way to serialize all of its types. how do you manage lifecycles for objects that have state referenced by other processes?
|
|
#
?
Feb 16, 2015 21:01
|
|
|
Subjunctive posted:how do you manage lifecycles for objects that have state referenced by other processes? Gee I don't know. I guess that's where 'isolated' and terms like 'share nothing' get their meaning.
|
|
#
?
Feb 16, 2015 21:59
|
|
|
MononcQc posted:isolated processes would mean you don't ever touch distributed GC. lol if your PL of choice doesn't have a way to serialize all of its types. the language the other process is written in probably can't deserialize your stuff into its own types painlessly. you wind up having to pick a common subset and implement deserialization for that subset on both ends. still worth it for a lot of uses, but not as obviously worth it as when each of your processes is written in the same language (or on different languages that share an object model and type system because they run on the same vm i guess)
|
|
#
?
Feb 16, 2015 22:09
|
|
|
That's where the microservices people chime in
|
|
#
?
Feb 16, 2015 22:15
|
|
|
Subjunctive posted:that's not my experience. you have to twist your type system into the QueryInterface model, do unnatural things for collections, deal with apartments and specific allocators, etc. some marshaling layers can hide chunks of that, but usually at substantial performance or fidelity cost. you can have two languages with perfectly normal class systems on opposite sides of a COM bridge, but in the absence of 1:1 coordination behind the back of the COM system neither side will have a natural mapping. well, as you pointed out, COM makes everything taste like early-90s C++. i'm not sure anyone would choose COM or early 1990s C++ as a base for language-independent libraries today, in 2015. at least i hope not Subjunctive posted:the problem is that Rust's type system is unlikely to be the lowest common denominator for a set of interoperating languages. how do you express Rust's generics in Python, or borrowing in Go? AFAICT you end up with a worse version of the marshaling problem in that each marshaling chunk needs to carry along a subset of Rust itself. this is very true, and it's also the status quo: to operate on a C-based platform, you end up carrying a lot of C around with you inside your other languages. when you port a language runtime to an alien platform, sometimes that requires some scary coping mechanisms. (this works both ways: porting C applications to openvms or z/os used to be really hairy)
|
|
#
?
Feb 16, 2015 22:24
|
|
|
MononcQc posted:Gee I don't know. I guess that's where 'isolated' and terms like 'share nothing' get their meaning. Please obey these rules for your posts.
|
|
#
?
Feb 16, 2015 22:25
|
|
|
Blotto Skorzany posted:the language the other process is written in probably can't deserialize your stuff into its own types painlessly. you wind up having to pick a common subset and implement deserialization for that subset on both ends. still worth it for a lot of uses, but not as obviously worth it as when each of your processes is written in the same language (or on different languages that share an object model and type system because they run on the same vm i guess) dont protobufs or capnproto or whatever solve this problem
|
|
#
?
Feb 16, 2015 22:27
|
|
|
something i find very cool is seeing new languages hosted on the CLR and JVM some languages adapt pick up the "calling convention" (easy interop with c#/java, global garbage collection) but try to stay as compatible with original unix-based implementation. ironpython and jruby fall into this category. you can port code directly from cpython-on-unix to ironpython-on-clr. others have borrowed general language designs, but gone their own direction in order to more fully integrate into their new environment. F# would be immediately familiar to an ML-family developer, but you wouldn't try to port OCaml or Haskell code directly across. see also clojure vis a vis common lisp. the first approach reminds me of unix code ported to z/os or minicomputers the second approach is its own wild thing
|
|
#
?
Feb 16, 2015 22:28
|
|
|
Blotto Skorzany posted:the language the other process is written in probably can't deserialize your stuff into its own types painlessly. you wind up having to pick a common subset and implement deserialization for that subset on both ends. still worth it for a lot of uses, but not as obviously worth it as when each of your processes is written in the same language (or on different languages that share an object model and type system because they run on the same vm i guess) yeah, but look at what you have to do to talk to c, it's not painless at all, you still have to ingest a foreign thing how is that different than using protobufs or thrift or whatever, you are just using c as an (hand written) IDL e: f;b
|
|
#
?
Feb 16, 2015 22:29
|
|
|
I'm curious now, what's so crazy about porting poo poo from VMS or zOS? That's a little before my time Only thing that comes to mind is that the zero page on VMS was a read-only page filled with zeros (and some programs made use of this) as opposed to a page filled with <SEGMENTATION FAULT> but a UNIXy C program would of course never try to dereference NULL, so I can't see how that would be a problem.
|
|
#
?
Feb 16, 2015 22:33
|
|
|
Notorious b.s.d. posted:something i find very cool is seeing new languages hosted on the CLR and JVM with corefx we're finally going to see two competing cross-platform VM metaplatforms and it's going to be really interesting to see what will happen what if we see a return to lisp machine like hardware with processors that implement JVM/CLR in microcode both F# and clojure are amazing we need to re-establish a baseline and then stop reinventing the things that are underneath it if we want to move forward
|
|
#
?
Feb 16, 2015 22:36
|
|
|
technically people also stick to a subset of C when they do interop i mean you could use bitfields in your portable ffi but ha ha ha no really just use explicit bitmasks you crazy person. and never pass or return aggregates by value, what is wrong with you
|
|
#
?
Feb 16, 2015 22:39
|
|
|
Mr Dog posted:I'm curious now, what's so crazy about porting poo poo from VMS or zOS? That's a little before my time you know all the things that are "implementation defined" in ansi C? every single one of those is different on VMS z/OS's C environment is a lot less weird because they ported a lot more of unix into it. to the point where it comes with bash Notorious b.s.d. fucked around with this message at 22:43 on Feb 16, 2015 |
|
#
?
Feb 16, 2015 22:40
|
|
|
Dessert Rose posted:what if we see a return to lisp machine like hardware with processors that implement JVM/CLR in microcode this happened already, twice 1. azul systems made custom hardware with support for write barriers in memory https://www.youtube.com/watch?v=5uljtqyBLxI they were really cool but i don't think they sell them anymore because x86 got enough features to make a port of the azul JVM viable 2. there was an optional ARM subset that could execute java bytecode directly it was slower than just running a JIT JVM directly on ARM so it disappeared Dessert Rose posted:we need to re-establish a baseline and then stop reinventing the things that are underneath it if we want to move forward for 30 years that baseline was UNIX on a microcomputer now it's a cool "vm metaplatform"
|
|
#
?
Feb 16, 2015 22:44
|
|
|
http://www.azulsystems.com/products/vega/overview oh you can still buy the custom hardware i've never seen one of these but man
|
|
#
?
Feb 16, 2015 22:45
|
|
|
Subjunctive posted:how do you manage lifecycles for objects that have state referenced by other processes? Event loops and pipe file descriptor passing! When a resource is allocated make a pipe, pass the write end to another process over a UNIX domain socket, close the write end in your process and put the read end in your select loop. When you get an EOF on the read end no processes are holding references to the object as they've either closed the file descriptor or died.
|
|
#
?
Feb 16, 2015 23:52
|
|
only
|
you could have just said "shared memory" but uh i guess if you want to get a raging hardon about the minute details that make it happen...
|
|
#
?
Feb 17, 2015 00:01
|
|
|
Shared memory and polling on the closing of a pipe have nothing in common. The latter is more eventfd than memfd.
|
|
#
?
Feb 17, 2015 00:06
|
|
|
MononcQc posted:Gee I don't know. I guess that's where 'isolated' and terms like 'share nothing' get their meaning. gee!  isolated things don't usually communicate at all, so let's not get all "according to Merriam-Webster" like some grade-school essay. it's great if you can express all your systems as 32-bit network-order integers, I agree. defining away the problem by saying "don't interoperate where it would require mutual expression of state" seems facile even by the standards of YOSPOS. isolating elements of your system where possible is great, and when building server/network stuff it's a good architectural bent. it tends to not work as well for things like mobile or desktop software where performance and resource consumption concerns are different. if I want to draw with Direct3D, a C++ API, from my Rust application, how do you propose I isolate that? there are contexts with meaningful state, and they're required for effective operation of the system. their lifecycles matter. how do you deal with any widget system without taking a reference to different parts of the widget graph? even "just" remoting POSIX filesystem semantics requires a substantial amount of state to be managed in a distributed way. "write everything from scratch to be remoted without state" basically ignores the problem, and many systems can't be effectively manipulated without long-lived state. people punch down into other languages to get library services, and process-remoting your crypto or image manipulation or audio mixing or physics isn't feasible in a lot of domains. do you really think that people have state only because they're stupid? not all applications are idempotent or pure.
|
|
#
?
Feb 17, 2015 00:53
|
|
|
They should be though 
|
|
#
?
Feb 17, 2015 01:01
|
|
|
MononcQc posted:They should be though can't ship "should"
|
|
#
?
Feb 17, 2015 01:03
|
|
|
rjmccall posted:and never pass or return aggregates by value, what is wrong with you Why don't people do this even within C, anyway? Is that just not a thing ABIs standardize?
|
|
#
?
Feb 17, 2015 01:09
|
|
|
Subjunctive posted:can't ship "should" Lots of stuff should never have shipped
|
|
#
?
Feb 17, 2015 01:24
|
|
|
Subjunctive posted:can't ship "should" username/post
|
|
#
?
Feb 17, 2015 01:30
|
|
|
Subjunctive posted:how do you manage lifecycles for objects that have state referenced by other processes? just never delete anything becusae disk/memory is cheap
|
|
#
?
Feb 17, 2015 01:40
|
|
|
pre-ANSI C compilers usually didn't support passing or returning aggregates by value; ofc ANSI C is more than twenty-five years old, but... i've never seen an ABI that didn't have rules for passing or returning aggregates; the problem is that those rules are often totally different on different platforms and can get pretty complex. also i've heard that msvc keeps changing them for at least one of their calling conventions? also there are dumb platforms where passing or returning a struct containing a single thing is actually less efficient than just passing that thing anyway, if you're writing code that needs to interop with non-C compiler output, you could either painstakingly make sure your compiler matches the C struct-passing ABI on all your supported platforms, probably for the sole benefit of one specific runtime function, or you can slightly tweak that one function to not pass that struct by value
|
|
#
?
Feb 17, 2015 01:54
|
|
|
rjmccall posted:i've never seen an ABI that didn't have rules for passing or returning aggregates; the problem is that those rules are often totally different on different platforms and can get pretty complex. also i've heard that msvc keeps changing them for at least one of their calling conventions? also there are dumb platforms where passing or returning a struct containing a single thing is actually less efficient than just passing that thing microsoft's c# compiler and microsoft's c++ compiler do not always agree on how structs should be laid out by default i am sure there is some reasonable-sounding explanation for this but it makes p/invoke more of a pain than i feel like it should be
|
|
#
?
Feb 17, 2015 02:00
|
|
|
GrumpyDoctor posted:microsoft's c# compiler and microsoft's c++ compiler do not always agree on how structs should be laid out by default c and c++ have struct layout rules that do not necessarily lead to optimal packing. c# doesn't want to promise c layout compatibility by default for all structs regardless of whether they are used with p/invoke because that would be really dumb. c# doesn't want to automatically detect whether you're using a struct with p/invoke because reasons (good reasons). asking you to be slightly more explicit in your unusual case is not unreasonable the better thing would be to derive the layout from an actual c header, but that does create a few additional problems
|
|
#
?
Feb 17, 2015 03:11
|
|
|
MononcQc posted:Just use isolated processes and talk by message passing epic thissery
|
|
#
?
Feb 17, 2015 06:56
|
|
|
hey you guys rust dropped it's runtime a while ago. here's how you call rust from c http://mainisusuallyafunction.blogspot.com.au/2014/08/calling-rust-library-from-c-or-anything.html
|
|
#
?
Feb 17, 2015 08:56
|
|
|
This thread makes me wish I had a CS degree.
|
|
#
?
Feb 17, 2015 11:01
|
|
|
KARMA! posted:This thread makes me wish I had a CS degree. i do and i don't understand anything that hackbunny or MononcQc says, they're both specialists in their language/field of choice and a CS degree won't help if you don't know that lang.
|
|
#
?
Feb 17, 2015 12:56
|
|
|
also more importantly, tons of industry experience too
|
|
#
?
Feb 17, 2015 13:08
|
|
|
Suspicious Dish posted:Can you even make a program that doesn't link to msvcrt? I'd be as surprised as making a program that doesn't link to glibc. you can link statically to libcmt.lib, and then you'll only import from kernel32.dll what I was talking about was the fact that every compiler and version of each compiler has its own version of the C runtime, each version in a separate DLL, each DLL a separate instance of the runtime, with separate tables of FILEs and other resources. if your software is written under the assumption of a single C runtime instance shared by all code in a process, you'll tend to treat the C runtime as a generic platform abstraction and do things like returning/taking FILE *, returning pointers allocated with malloc, etc. all of which are spectacularly bad ideas on Windows, all of which things Cpython does IIRC, requiring you to compile any binary modules with the exact same compiler/runtime as the runtime's Subjunctive posted:JS to COM-like reference counting XPCOM? hackbunny fucked around with this message at 13:38 on Feb 17, 2015 |
|
#
?
Feb 17, 2015 13:29
|
|
|
KARMA! posted:This thread makes me wish I had a CS degree. same except glad that i dont
|
|
#
?
Feb 17, 2015 14:48
|
|
|
|
| # ? Jun 11, 2024 00:46 |
|
|
rjmccall posted:pre-ANSI C compilers usually didn't support passing or returning aggregates by value; ofc ANSI C is more than twenty-five years old, but... I am implementing a programming language that compiles to C, and I was going to make the resulting functions return structs. Is this a bad idea? The idea is that the C code would be compiled alongside whatever program you want to use it in, so the same compiler. I just never see C APIs return structs by value for some reason.
|
|
#
?
Feb 17, 2015 14:55
|
|
