Index: [thread] [date] [subject] [author]
  From: Marcus Sundberg <e94_msu@elixir.e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Tue, 04 Aug 1998 21:45:27 +0200

Re: setinfoflags and mansync changes

> > > Been trying to do the ggiSetInfoFlags changes,
> > 
> > What changes? Have I missed something?
> 
> Targets can override ggiSetInfoFlags(), rather than flags being silently
> set, usually to set mansync stuff.  Some patch I posted several weeks ago,
> now converting targets to use it.

Yes, I remembered that after posting my reply. :)

> > >    We'll leave it as taking no arguments for MANSYNC_CHILD, and all mansync
> > >    visuals should share the mansync_hook_with_a_clashpreventing_name hack so
> > >    you can use e.g. X and AAlib sync mode together.
> > 
> > Yes, this is a good idea.
> > But it will require that the mansync-handling code be moved either
> > into the core libggi or into a helper-mansync library.
> > I vote for the latter.
> 
> The whole mansync-handling code, or just the little structure?

If multiple visuals is to use MANSYNC_CHILD simultaneously
there must be exactly one process sending the signal to the
main process and exactly one signal-handler catching it,
so basicly all mansync-code have to be in a global
place.

> > This also reminds me that I still think dlopen()ing the same
> > library several times is a bad idea, because I don't think
> > the reulting behaviour is really defined.
> > 
> > Is there any reason we shouldn't cache opened libraries and
> > keep a usagecount on them?
> 
> The manpage says:
> 
>        If the library exports a routine named  _init,  then  that
>        code  is  executed  before  dlopen  returns.   If the same
>        library is loaded twice with dlopen(), the same file  han-
>        dle is returned.  The dl library maintains link counts for
>         dynamic file handles, so a dynamic library is not  deallo-
>        cated until dlclose has been called on it as many times as
>        dlopen has succeeded on it.
> 
> Or it is unportable, implementation-defined/unspecified/undefined behaviour?

Hmm, the SunOS manpage says the same thing, and the Digital Unix
manpage says nothing at all. Win32 I don't know about at all.

I suppose we can leave it as it is until we find a platform
that causes trouble.

//Marcus

Index: [thread] [date] [subject] [author]