RE: Problems while switching C stacks (fibers)
- From: William Adams <william_a_adams@xxxxxxx>
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Mon, 9 Sep 2013 12:20:24 +0000
Personally, I'd use message queues to manage any shared state.
It will save you a whole lot of headaches when later you decide
to use a few real preemptive threads here and there.
-- William
===============================
- Shaping clay is easier than digging it out of the ground.
________________________________
> Date: Mon, 9 Sep 2013 13:33:41 +0400
> Subject: Re: Problems while switching C stacks (fibers)
> From: lupus@xxxxxxxxxx
> To: luajit@xxxxxxxxxxxxx
>
> 2013/9/8 Mike Pall <mike-1309@xxxxxxxxxx<mailto:mike-1309@xxxxxxxxxx>>
> Well, before going that route, please remember this: shared memory
> is just an optimization.
>
> Can't shared memory be used as-is? We have a cdata that is used in
> several VM's and they just modify it's member values. This does not
> fall into message queues pattern and can barely be called a database :)
>
> I would just go this way, but i got stuck at the moment "hmm, now i want
> a hash table...". Probably I will just wrap khash generated functions for
> each target datatype into a header/library and will feed that header to cdef.
>
> In-memory database is another plausible solution, since we have some
> in-house implementation already...
>
> I guess you need to make your mind up about the inter-thread
> communication patterns first. Then decide on the most suitable
> communication mechanism and only then decide on an implementation.
>
> Since it's an application server, it's hard to foresee all possible
> usage patterns.
> Fibers library itself is designed for asynchronous circular buffers, or
> message
> queues, so this is another plausible communication pattern.
>
> We will try to figure this out and share the experience.
> Thanks for your input, Mike!
>
> --
> Regards,
> Konstantin
Other related posts:
