Re: Glib::Dispatcher1<T>

[Daniel Elstner <daniel kitta googlemail com>]

Am Samstag, den 20.01.2007, 19:16 +0000 schrieb Chris Vine:
> On Saturday 20 January 2007 13:07, Daniel Elstner wrote:
> >
> > Only for the pointer specializations (and not really *around* the
> > read/write, I got that wrong in my proposal mail).  And even for pointer
> > types this will be only the default behavior.  If you know what you're
> > doing (e.g. when passing a pointer to static data), you may disable the
> > extra lock/unlock.
> 
> I see, that looks good, except that the fact that data are static doesn't make 
> them automatically visible (possibly some particular implementations do, I am 
> not sure) - two threads can see different values for static data if the data 
> have recently been modified.  But data passed by value over the pipe are as 
> you say entirely safe.  The point is not whether data are allocated on free 
> store (if that is what you mean by dynamic)  but whether they require 
> dereferencing to address objects in memory not passed by value.

By static I meant unchanging over the lifetime of the thread.  I know
that dereferencing is the issue here.  But if the data in question was
only written to before the thread was created, or if you synchronize
access yourself by other means, it is perfectly safe to dereference.

> On a completely different point, also applicable to Glib::Dispatcher: the 
> Posix standard guarantees atomic writes to pipes between different processes 
> where the data is PIPE_BUF or less in size, but not between different threads 
> in the same process.

What the fuck?!  The GNU C library manual doesn't make it sound like
that; it says "that nothing else in the system can observe a state in
which it is partially complete".  Of course, the glibc manual is not the
POSIX standard.

> I agree that an implementation would have to work hard 
> not to have atomic writes between threads if it does so between processes, 
> but it isn't formally guaranteed.  If you were worried about it you could put 
> a mutex around the call to write().  (I would not be worried if I were using 
> Linux.  I could not hazard a guess about other Unix-type OSs.)

Well until now no-one has complained about the (non-)atomicity of the
current Dispatcher, and people have at least been compiling it on
various Unices I have never laid an eye on.  The whole issue sounds to
me like a simple omission in the POSIX standard, due to the relevant
parts having been written before POSIX threads came into being.  Well,
at least I hope it is that way.  Correct me if I'm wrong.

--Daniel