lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


It was thus said that the Great Coroutines once stated:
> On Sat, Aug 23, 2014 at 12:54 AM, Sean Conner <sean@conman.org> wrote:
> 
> >> >   Okay, now I'm totally confused as to what you are trying to do.  Let's
> >> > take, for example, LPeg.
> 
> Why would you turn to LPeg for an understandable example? 0.o

  Because elsewhere you said:

> I would like the option of peering into and modifying any userdata
> from Lua as if it were a string, with the string functions.  This
> would break security so I'd want to control this ability through the
> debug library.

  That's why.  So, yeah, LPeg example.

> >   Okay, you are definitely associating "userdata" with "large, growable
> > character array".  userdata is more than just that.
> 
> Userdata is 2 tables + commonheader? + data -- it seems very close to
> a character array to me :>

  In C, a structure is just a sequence of bytes.  In C, a string is just a
sequence of bytes.  Yes, in C, you can cast a structure pointer to a
character pointer and back again.  It doesn't mean that's a good idea.

> >   The Amiga did zero-copy message passing.  Upside:  it was quick.
> > Downsides:
> 
> I did read through the rest of your post but I feel like it's
> attacking what I want to do with userdata, not if userdata should be
> readable as strings in some way.  "We shouldn't have that because you
> can do something bad!"  Maybe you would be so kind as to let me reap
> my own rewards/failtures? :>  I do understand the risks of doing this
> incorrectly.

  But then don't be surprised when you ask us to help you fail and we
refuse.  Some of us here have already been down that road and are trying to
warn you about the dangers ahead.

> PS: I have never used a microkernel, I do not know of this inherent
> message-passing you speak of. 

  With the right point of view [1], a function call is just synchronous
message passing.  

> Also, I'm pretty sure people who do #3
> would resort to #2 to make that zero-copy.  You know lock-free
> algorithms are still a thing... a queue within a queue within a queue
> is good on you :D

  I think you missed my point.  You have this structure:

	struct somestruct
	{
	  int x;
	  int y;
	  char *name;
	};

  You want to pass that as a message.  It contains a pointer to some string. 
A zero-copy message passing scheme doesn't mean the memory pointed to by
name is included.  You still have to flatten the thing into a single block
of memory.

  And even a function call copies data ... 

  -spc (Think about it ... )

[1]	"A change in perspective is worth 80 IQ points." -- Alan Kay