Re: [dev] Suckless remote shell?

From: Alexander S. <alex0player_AT_gmail.com>
Date: Fri, 8 Nov 2013 02:10:49 +0400

2013/11/7 Szabolcs Nagy <nsz_AT_port70.net>:
> * Alexander S. <alex0player_AT_gmail.com> [2013-11-07 16:55:35 +0400]:
>> Context pointers for callbacks... well, they exist because of the
>> limitations of the type system. I'd rather see
>> ?A,[Types...].pthread_create(pthread_t*, A(*callback)(Types...), Types
>> args...) (so, arbitrarily many additional args for callbacks). A
>> type-checker can properly check it, and even in current calling
>> conventions, it's quite fast to handle: you just copy a chunk of
>> memory fro and to stack, wholesale. Failing that, there's always
>> ?A,B.pthread_create(pthread_t*, A(*callback)(B), B arg).
>
> with a single pointer arg this assumes that all pointers have
> the same representation or that you create a separate version
> of pthread_create for every type used
Pthread_create doesn't need to know anything about the type of the
pointer! In fact, nobody except the typechecker needs to.

> arbitrary number of args does not work: you need runtime type
> information for that (which is complex, slow and problematic
> to define the binary interface), var arg calls are not just
> passing a chunk of memory on the stack (would be suboptimal
> on archs like x86_64 with lot of registers)
Runtime information is only needed if you are going to actually
introspect that arbitrary number of args. If you are going to plop
them back onto the stack, the only thing you need to know is a total
size, which can be calculated in compile time.
As for amd64, I didn't mention it because that's, really, details.
va_list implementation solves the problem of native 64-bit calling
convention; surely we can, too. The only difficulty is the size of
arguments that need to be copied to and fro stack, and sadly, not
every widely-used type is the same width, even after standard
expansion C varargs undergo. But, I suppose, asking that all arguments
be either floating-point or pointer-size isn't asking too much. It is
doable.

>> mmap is another matter, but whether for turning file into RAM or for
>> IPC, it tends to have some structure, I guess?
>
> you can allocate memory with mmap and reuse it several times for
> different type of objects or you may need to parse the mmaped
> data so you don't know static types
Parsing is usually done with the stream (especially if you don't know
static types), but I suppose there are some use cases which include
random access AND heterogenous data. Well, not everything can be
perfect; that's what explicit casts are for.
Received on Thu Nov 07 2013 - 23:10:49 CET