Re: the state of the concurrency branch

[Stefan Monnier <monnier@iro.umontreal.ca>]

> The basic issue is that only one thread can select on a given fd at a
> time.

Why?

Stefan> --- src/eval.c	2013-08-20 03:53:07 +0000
Stefan> +++ src/eval.c	2013-08-26 20:54:04 +0000
Stefan> @@ -1119,6 +1119,7 @@
Stefan> c.next = catchlist;
Stefan> c.tag = tag;
Stefan> c.val = Qnil;
Stefan> +  /* FIXME: Why "f_"?  */
Stefan> c.f_handlerlist = handlerlist;
> The field needs some different name, because "handlerlist" is now a
> #define in thread.h.

Oh, I see, than makes sense.  In this case, I think it will be better
to replace uses of the `handlerlist' variable (maybe replace them with
TVAR(handlerlist)) rather than use a "handlerlist" macro so as to avoid
such problems.

The behavior of CPP "symbol macros" is pretty ugly, so we should try and
only use them for symbols that follow some naming convention (typically
being all-caps).

> Yeah.  The ordering is funky due to the #define hack.
> This could be done a different way; but the define approach at least
> makes merges simple; a big consideration for me given my extremely
> limited free time... a more invasive change would make merges very hard.

Makes a lot of sense.  But we should change it (shortly!) before merging
it into trunk.

> Somehow I wasn't aware that Emacs used bool.
> Is that new(-ish)?

Yes, it's newish.

Stefan> +/* FIXME: Why "m_"?  */
> I don't recall why "m" in particular, but it does need some prefix due
> to the #define approach.

Same as above, I'd rather use another macro that doesn't require such
renaming (and instead requires replacing some var-references by
macro-calls).

Stefan> +  /* FIXME: Why give it a name?  */
Stefan> /* The name of the mutex, or nil.  */
Stefan> Lisp_Object name;
> It's a debugging feature.  The name is optional for those who don't need it.

I see.  Not sure I like it, but maybe it's handy.


        Stefan