[Spice-devel] [RFC] server: add main_dispatcher

[Alon Levy]

On Thu, Sep 08, 2011 at 11:26:00AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 09/08/2011 11:18 AM, Alon Levy wrote:
> >On Thu, Sep 08, 2011 at 10:58:41AM +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 09/08/2011 09:31 AM, Gerd Hoffmann wrote:
> >>>Hi,
> >>>
> >>>>>simple object system, not unions). Just an idea, could be changed
> >>>>>later perhaps. socketpair is probably fine.
> >>>>
> >>>>First of all I see I forgot to add a mutex, since I said "any non main thread", right
> >>>>now we only have one, so no need to lock, but the idea is that it can also be called from
> >>>>others, and so we will need it later. (unless that write can be considered atomic, but
> >>>>I don't think it can)
> >>>
> >>>A single write system call is atomic.
> >>
> >>Yes and no, this is true, except when the write blocks after writing part of the
> >>message, once that happens all bets are off. I think we may have several cases
> >>where we don't check for this. At the minimum we should assert (and not ASSERT)
> >>when a write returns a wrong number of bytes written (iow it managed
> >>to write some but not all of the message).
> >
> >Can that happen in a normal order of events? or is that a thing that really merits
> >crashing the process?
> 
> Define normal, I think the kernel will buffer up to 16k (or maybe only 4k ?) before blocking,
> so if the producing side manages to write 16k before the consumer gets around to consuming
> any you will hit this. This seems an exceptional circumstance, so I think crashing is an
> ok answer to this.
> 
> We should either handle this gracefully (which means extra code + locking for something
> which should never happen), or at least catch the should never happen case.
> 

ok. I guess I'll add an assert (not ASSERT). I'm still looking at the pulseaudio IPC - it looks
like asyncmsgq is good for what we need - it's meant for multiple writer single reader, where the
reader is a realtime thread, but should be fine if the reader is not. It would drag quite a lot
of the pulseaudio support files - fdsem, asyncq, asynqmsg, some macro.h stuff. Or maybe it's already
been split off by someone?

> Regards,
> 
> Hans
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel