Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2006-12

Proposed change in simpleipc

11 messages · 8 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Luiz Americo Pereira Camara

While developing with simpleipc i found that there's no straightforward way to identify the type of a message (see the forth paragraph of http://lazarusroad.blogspot.com/2006/12/only-one-instance.html), so i looked what i could do to improve it.

Currently, TMessageType is defined as an enum type with two possible values: mtString and mtUnknow. If you use SendMessage mtUnknow is used if SendMessageString is used mtString is used. But the message type is not being used: under windows the message type is not even passed to the server, under linux is passed but not used.

What i propose is simple: change the TMessageType to an 32bit ordinal type (longint or longword), provide ways the user to send custom message types and add a MsgType property to IPCServer. This way the user (programmer) can send messages with different purposes and easily know what to do when they arrive. Some thing like that:

with IPCServer do
  begin
    case MsgType of
      mtString:;
      mtMyType1:;
      mtMyType2:;
    end;
  end;

The patch i'm sending does:

- Change TMessageType to longint
- Define mtString and mtUnknow as constants
- Add overloaded methods SendMessage and SendMessageString with an extra parameter (MsgType)
- Added MsgType property to TSimpleIPCServer
- Changed some capitalizations

win32
- MsgType is passed through an unused CopyDataStruct field

unix:
- No changes at all, just fixed a bug (mtString was used always)

Notice that there's no memory or resource increase since the patch uses previously unused resources.
I'm sending also a test program written in Lazarus. It was tested under win32 and linux (ubuntu 10.06)

Luiz

Kris Leech
to Luiz Americo Pereira Camara: While developing with simpleipc i found that there's no straightforward way to identify…
Luiz Americo Pereira Camara wrote 5 lines
While developing with simpleipc i found that there's no straightforward way to identify the type of a message (see the forth paragraph of http://lazarusroad.blogspot.com/2006/12/only-one-instance.html), so i looked what i could do to improve it.

Look forward to reading more, anyone else have a laz/fpc blog?

Vincent Snijders
to Kris Leech
Kris Leech wrote 9 lines
Luiz Americo Pereira Camara wrote: > While developing with simpleipc i found that there's no > straightforward way to identify the type of a message (see the forth > paragraph of > http://lazarusroad.blogspot.com/2006/12/only-one-instance.html), so i > looked what i could do to improve it. Look forward to reading more, anyone else have a laz/fpc blog?

A couple of days ago, I gathered some links on
http://wiki.lazarus.freepascal.org/Lazarus_Documentation#Lazarus_related_blogs

Vincent

Vlad
to Michael Schnell

Hello.

I made dylib with FPC (compiled in delphi mode if it is important). I have functions that I want to export listed in "exports" section, a few hundreds exported and that works fine but when I run otool it shows me thousands - class methods, functions, almost everything, and it seems like this symbols take a lot of space in the dylib, almost half of it. And I cannot strip them. Can anybody explain what it the reason why they are exported?

Thanks.
Vlad.

Jonas Maebe
to Vlad
Vlad wrote 7 lines
I made dylib with FPC (compiled in delphi mode if it is important). I have functions that I want to export listed in "exports" section, a few hundreds exported and that works fine but when I run otool it shows me thousands - class methods, functions, almost everything, and it seems like this symbols take a lot of space in the dylib, almost half of it. And I cannot strip them. Can anybody explain what it the reason why they are exported?

If you compile a dynamic library with FPC, it automatically statically links in a copy of all units you use in that library (also RTL units). You cannot strip these, since they are used by the library code (and smart linking, or dead code stripping as Apple calls it, is not yet supported on Mac OS X due to bugs in Apple's linker).

The reason they are also exported, is that they are global symbols (i.e., they appear in the interface of a unit). I know the manual states that no symbols will be exported unless you mention them in the export statement, but afaik this is wrong in general (except maybe on Windows?)

Jonas

Florian Klaempfl
to Jonas Maebe
Show quoted text 21 lines
On 19 dec 2006, at 15:50, Vlad wrote: > I made dylib with FPC (compiled in delphi mode if it is important). I > have functions that I want to export listed in "exports" section, a > few hundreds exported and that works fine but when I run otool it > shows me thousands - class methods, functions, almost everything, and > it seems like this symbols take a lot of space in the dylib, almost > half of it. And I cannot strip them. Can anybody explain what it the > reason why they are exported? If you compile a dynamic library with FPC, it automatically statically links in a copy of all units you use in that library (also RTL units). You cannot strip these, since they are used by the library code (and smart linking, or dead code stripping as Apple calls it, is not yet supported on Mac OS X due to bugs in Apple's linker). The reason they are also exported, is that they are global symbols (i.e., they appear in the interface of a unit). I know the manual states that no symbols will be exported unless you mention them in the export statement, but afaik this is wrong in general (except maybe on Windows?)

IIRC it's true for Linux too.

Jonas Maebe
to Florian Klaempfl
Florian Klaempfl wrote 9 lines
> The reason they are also exported, is that they are global symbols > (i.e., they appear in the interface of a unit). I know the manual > states > that no symbols will be exported unless you mention them in the > export > statement, but afaik this is wrong in general (except maybe on > Windows?) IIRC it's true for Linux too.

Not in my experience (this is tests/test/tlibrary1 on Linux/i386):

$ nm libtlibrary1.so |less
00006450 A __bss_start
00031ea9 T DEBUGEND_SI_DLL
00031e60 T DEBUGEND_SYSTEM
00035858 D DEBUGINFO_SI_DLL
000320e0 D DEBUGINFO_SYSTEM
00031e60 T DEBUGSTART_SI_DLL
00019770 T DEBUGSTART_SYSTEM
00032000 A _DYNAMIC
00006450 A _edata
00006450 A _end
0001ca60 T fpc_abs_real
00029610 T FPC_ABSTRACTERROR
00029610 T fpc_abstracterrorintern
00028490 T fpc_addref
00028490 T FPC_ADDREF
00020890 T fpc_ansistr_append_ansistring
00020890 T FPC_ANSISTR_APPEND_ANSISTRING

All these "T" symbols are exported afaik.

Jonas

Florian Klaempfl
to Jonas Maebe
Show quoted text 32 lines
On 19 dec 2006, at 17:23, Florian Klaempfl wrote: >> The reason they are also exported, is that they are global symbols >> (i.e., they appear in the interface of a unit). I know the manual states >> that no symbols will be exported unless you mention them in the export >> statement, but afaik this is wrong in general (except maybe on Windows?) > > IIRC it's true for Linux too. Not in my experience (this is tests/test/tlibrary1 on Linux/i386): $ nm libtlibrary1.so |less 00006450 A __bss_start 00031ea9 T DEBUGEND_SI_DLL 00031e60 T DEBUGEND_SYSTEM 00035858 D DEBUGINFO_SI_DLL 000320e0 D DEBUGINFO_SYSTEM 00031e60 T DEBUGSTART_SI_DLL 00019770 T DEBUGSTART_SYSTEM 00032000 A _DYNAMIC 00006450 A _edata 00006450 A _end 0001ca60 T fpc_abs_real 00029610 T FPC_ABSTRACTERROR 00029610 T fpc_abstracterrorintern 00028490 T fpc_addref 00028490 T FPC_ADDREF 00020890 T fpc_ansistr_append_ansistring 00020890 T FPC_ANSISTR_APPEND_ANSISTRING All these "T" symbols are exported afaik.

Strange, I thought I fixed this. Might have been something different ;)