Re: threadlib and emacs

On 07/19/11 18:00, Bruno Haible wrote: > What is this AC_CACHE_CHECK good for? I've listed all the portability bugs > that were encountered during porting in > doc/posix-functions/pthread_sigmask.texi, and a wrong signature was not > among the problems found. Sorry, I expect that I misremembered a

Re: threadlib and emacs

Hi Paul, > It's fine that Gnulib supports > threadlib, but Gnulib shouldn't insist on threadlib as opposed to > POSIX threads. > ... > POSIX threads are not perfect, but they're part of a standard > interface that is reasonably well understood and they are good enough > for many applications. Gnu

Re: threadlib and emacs

On 07/18/11 17:38, Bruno Haible wrote: > [the new patch] does not address the points 1) and 2) of > . That comment's point (1a) is the claim that some more-complicated and not-yet-implemented approach would be better. Perhaps it

Re: threadlib and emacs

Paul, > > I suppose another possible hack is to replace the ifdef with > > something like m4_ifdef([gl_[]THREADLIB], ...); I haven't > > investigated that. > > I tried that, and it seems to work. It strikes me that > other gnulib macros play the m4_ifdef trick too, e.g., > gl_FUNC_WRITE does m4_

Re: threadlib and emacs

Hi Paul, > It's not unusual for applications to want to use POSIX threads > without also wanting to use threadlib. Of course many applications make use of POSIX threads, without using gnulib, or using gnulib but not threadlib.m4. But they do so at the price of - having lots of platform dependen

Re: threadlib and emacs

On 07/17/11 18:00, Paul Eggert wrote: > I suppose another possible hack is to replace the ifdef with > something like m4_ifdef([gl_[]THREADLIB], ...); I haven't > investigated that. I tried that, and it seems to work. It strikes me that other gnulib macros play the m4_ifdef trick too, e.g., gl_FU

Re: threadlib and emacs

On 07/17/11 15:10, Bruno Haible wrote: > the changes are ONLY useful for Emacs. No, they are useful for other packages too. It's not unusual for applications to want to use POSIX threads without also wanting to use threadlib. Coreutils does that too. For example, suppose we wanted to improve t

Re: threadlib and emacs

Hi Paul, > Here are two proposed patches to get Emacs to work with gnulib > pthread_sigmask. The idea is that GNU Emacs will use --avoid=threadlib. > > The first patch is for gnulib-tool, the second for pthread_sigmask; > the second depends on the first. The second patch is intended to > change

Re: threadlib and emacs

Here are two proposed patches to get Emacs to work with gnulib pthread_sigmask. The idea is that GNU Emacs will use --avoid=threadlib. The first patch is for gnulib-tool, the second for pthread_sigmask; the second depends on the first. The second patch is intended to change the behavior of the p

Re: threadlib and emacs

Paul Eggert wrote: > Please feel free to apply it now, since Emacs isn't > using the gnulib version of pthread_sigmask.m4 now. Thanks for agreeing. I've pushed it now. Bruno 2011-07-12 Bruno Haible pthread_sigmask: Rely on module 'threadlib'. * modules/pthread_sigmask (Depen

Re: threadlib and emacs

On 07/09/11 03:16, Bruno Haible wrote: > So, I would like to apply this sooner than later: Please feel free to apply it now, since Emacs isn't using the gnulib version of pthread_sigmask.m4 now. That patch won't work with Emacs, because it'll run afoul of the problem described in

Re: threadlib and emacs

Hi Paul, > I was asked to stop installing this sort of change into Emacs > for now, as it's in feature freeze. At some point we'll reopen > the Emacs trunk for general changes and then we can revisit > this issue. Or, we can revisit the issue if there's > an actual bug. But in the meantime, m4/

Re: threadlib and emacs

On 07/08/11 18:31, Bruno Haible wrote: > Does that sound feasible? It might work, yes, though it'd need some experimentation. As it happens, I got your email at about the same time that I was asked to stop installing this sort of change into Emacs for now, as it's in feature freeze. At some poi

Re: threadlib and emacs

Hi Paul, > I looked at the current non-threadlib implementation again in the light of > your > comments, and I now think that it goes too far, as it fusses with > LIBS and so forth.  I'd rather have something even simpler. > > I see that you're now working in that area, but > once things have se