What is wrong with the standard 'ssockets' unit ? It works fine. It may be necessary to add some additional events, but that can be discussed.

Then I misunderstood the thread. Sorry.

Just ignore. I'll dig into them in a week or so and see what I can come up with.

-Tony

Oh, BTW: CheckBook Tracker got slashdotted (minor) on Sunday. Somebody posted in the comments on a QuickBooks thread that people should try it...

Quoting Anders Jensen :

Problem is larger in some ways than it seems. First major problem is that sockets in ssockets unit don't respect kernel specifications for this kind of communications.

Basically,
1. In linux accept (there is no check mode, accept just waits until it gets result) should be run in a thread.
2. When accept is invoked another thread should be invoked which creates a socket and this socket communicates with a client. To conclude,
No multithreading, no fun

I'm making a CS socket communication and I've succesfully made all the components I need, which I would be glade to contribute (as well as few bugs, more likely security bugs and their solutions). There's just a fact that sockets are not 100% tested and I'm still making a TInetJob queue which takes care if there are more then one job for the same communication eg. copying multiple files in different directions. They will be completed in friday (that's my deadline for the project (mostly lazarus and bash cooperation) I've been working last 7 months and communication is the last part of it). Just tell me where to drop them or whom to send if you're interested. But I've corrected only TInetSocket not TUnixSocket, which can just follow my example with Inet.

And explanation for security bugs.
There are some problems in your components, mainly involving forceably exiting software after a bug. I understand that's common in Windows environment but Unix isn't like that. Sockets have that one too. But there is a nicer example.

bug (XML#1)
1. Take xml file
2. Add some garbage at the end
3. Try to read it
4. Program exits with error
5. Mistake, it shouldn't do that, program might change it's running UID to root meanwhile, so exiting would make current user root.

bug (sockets#1)
1. Client tryes to make communication that doesn't exist
2. Program invokes error
3. Read 5 in XML bug

All of your security bugs are involved in the same manner of exiting, so instead of exiting with an error I just invoked Success: boolean which tells if component is successful or not and TInvokeError with a console, log or gui mode that reports error unpainfully, leave the rest to the program for correct execution of exit if that's needed.

On the other hand, I'm making some special system services and deamons that must change UID, GID and all others system vars constantly in the runtime, probably typical Lazarus app isn't intended to do that, so I guess that with that bugs or without lazarus is a great app that helped me a lot.

bye

-------------------
http://www.email.si

Har anyone any knowledge about working with sockets in Lazarus?
I`m tearing my hair off here (and has little of it as it is) ,� trying to make
a simple little p2p chat-client�on SuSE 8.0, nuthin seems to work using
the sockets-unit in FPC... or maybe I`m just doin it all wrong (very possible)
�
AJ

Because the 1.0 RTL is not thread safe. The exception stack is shared across threads, this is what causes your problem. This should be solved in the 1.1 compiler, but the thread support is not yet stress tested, although tests seem to indicate that it works fine.

Why not use fork() and child apps ? You should have no problems then. You can use shared memory to communicate between the threads if you need that.

Michael.

I've been following this thread and was wondering...

Does anyone then have a _working_ threaded or async sockets unit that I could use to build a non-visual control on? That way we can change this into a drag-n-drop control from the palette.

Thanks,

Tony

Tony Maro wrote

Oh, BTW: CheckBook Tracker got slashdotted (minor) on Sunday.

So your web server did survive it ;) ?

Read 'Advanced programming in the UNIX environment' by W.R. Stevens and you'll find reasons to do the opposite. Look, I'm not saying that thread programming is wrong. It is one way. Asynch programming is another way, avoiding threads. Threads solve some issues, but they do raise other issues in programs. If you're a german speaker, I suggest you buy the 'Kylix in Team' book; there I show different approaches to programming linux sockets, with and without threads.

Also, don't forget that the Linux kernel (except the new development kernel) has no real threading, A thread from the kernelpoint of view is just a process sharing it's data segment with another process. No special thread optimizations or so exist. I don't say anything about the latest development kernels, I know that special thread functions have been implemented there. But the stable kernel has nothing for threads.

The solution should not assume anything about the way the things are programmed other than that it uses classes, streams and exceptions. The ssockets implementation can and should be used with or without threads.

Yes.

I suggest you check the code again, line 138:

procedure TXMLReader.RaiseExc(descr: String);
var
  apos: PChar;
  x, y: Integer;
begin
  // find out the line in which the error occured
  apos := BufStart;
  x := 1;
  y := 1;
  while apos < buf do begin
    if apos[0] = #10 then begin
      Inc(y);
      x := 1;
    end else
      Inc(x);
    Inc(apos);
  end;
  raise EXMLReadError.Create('In ' + Filename + ' (line ' + IntToStr(y) + ' pos     IntToStr(x) + '): ' + descr);
end;

the XMLReader.ExpectProlog you refer to, calls this method.

About unallocated memory: Programs that use exceptions should always cater for exceptions. This includes releasing memory when an exception occurs.

There is no 'bug'; it just doesn't work as you expect, I guess.

I'm not saying that the connect method cannot be improved. We can add a handler that gets called when the connect fails and throw the exception if there is no such handler, but we should not assume threads. If this doesn't fit your specific needs, then you'll have to find another solution.

Michael.

FPC had quite a lot of fun when it reached 1.0. The first few mirrors in the list were completely unreachable for several weeks ;-)

Quoting Michael Van Canneyt :

So, I did.
But last time I was making a suggestion, there was all talk and talk and talk. But nobody did something. Ok, I did what I needed but you obviously weren't prepared to take it as I suggested, so I completed my suggestion for my use and you probably did yours I really don't know because until week ago I was still working with the same version as almost a year ago. Now that I'm finished with my project I can finally move on (I really hated new delphi version, so I never trust nobody to swap the tool I'm using between a project in work). But what I saw was two things, except Interfaces, everything worked out fine, great work every time delphi got upgraded I almost suffered mental attack. And some bugs that stayed the same as I noted "in my special conditions".

Read the book "The Linux Kernel". It explains all. No threading one connection or you're going the wrong way against the principles of suggested kernel programming.

So I will, but my solution is heavy on threading already in motion. If that's no problem? My guess after reading your response is that you don't like that.

So, I should???? heh, ???in XMLReader.ExpectProlog that function throws out if there is something after the end, and notify nobody that it is unsuccessful. Component is not assigned and result is not nil, a bug I guess.

There is no exceptions in XMLRead, at least I haven't seen them. And if I produce exception I finally get a load of unspecied allocated memory.

Problem is "not all xml files get written by your component, beacuse if file is written with it it's complying with xml specifications", make one from a script or some other language that produces xml file with a bug.

So, is it a bug or not??? You decide.

  FConnected := Sockets.Connect(ASocket, addr, sizeof(addr));
//  If not Sockets.Connect(ASocket, addr, sizeof(addr)) then
//    raise ESocketError.Create(seConnectFailed, [Format('%s:%d',[FHost, FPort])]);

and tell me why there should be exception on trying to connect. Nicer way, connect runs in thread and tryes to login. Cancel thread cancel connection, or too many tryouts cancels connection. Bug occurs in a simple console application, in gui application your exception throws out dialog with a message, in console, guess what whole software gets thrown out, exception or not, at least for me.

There's no mixing, but simple explanation. The work I do is system only, almost no gui. You obviously haven't really tested more clearly before you commented. I noted that I'm changing GID and UID runtime and I'm always using heavy threading and most of all I'm combining different languages, and that's where the problems are in "multiuser", so yes they are bugs in certain conditions that do not meet classical Lazarus app as I noted in my previous answer.

-------------------
http://www.email.si

Quoting

Kylix in team? God, I've bought all of them and even v.3 doesn't measure up my needs. But all of the examples in Kylix are made with threads, at least socket c/s>everything components pack.

My next app deadline is july(first beta) and october (final), so you can guess which one I preffer. Suggested in that time.

ups, I missed that one. but I still wonder why jumps out in heavy threaded console app. simple app works fine with this exception.

i guess i'll just work around my way. it's funny i tried two other methods that get blown in heavy threading. in simple app they work just fine. unfortunatelly simple apps is not what i need. on the other hand major tread doesn't cause any problems with exceptions.

yep, i guess

I did it already, thanks anyway I simply inherited TThreadedInetServer and TThreadedInetSocket (and I left original intact so I've got both solutions) out of sockets based in ssockets and everything is working like a charm. As I said 2.6 is what I'm waiting.

m.

-------------------
http://www.email.si

What is wrong with the standard 'ssockets' unit ? It works fine. It may be necessary to add some additional events, but that can be discussed.

Michael.

Well, I run Apache after all ;-)

Like I said, it was a minor slashdot contained within the comments... thankfully!

I run my server on my DSL line, so I could only imagine what a real slashdot would do to me!

Well, why don't you communicate what the problems are, maybe we can solve them ?

This is not needed when running asynchronous IO. There are examples of a webserver written in FPC using asynchronous IO. Threadprogramming makes some things easier, but is not required at all.

You can send patches to me or to sebastian guenther ()

You should put a try/except block around it of course. this is common programming technique in Object Pascal.

See same solution.

You cannot mix normal 'procedural' programming techniques and class programming using exceptions. The 'bugs' you report are not bugs, they are normal program behaviour, only you're supposed to follow the programming rules under which the components were constructed. If you don't (and you obviously don't) then you will of course interpret this as 'bugs'.

Michael.

Quoting

ok, i'll wait on that one

although tests seem to indicate that it works fine.

yep, up to 70 threads are working very, very smooth. Tested, except the exceptions (as funny as it sounds).

It will not be as effective as threads as I read.

You can use shared memory to communicate between the threads if you need that.

as I pointed out I wanna be more 2.6 compliant, mostly because of second pack of app, which will run on a completely new server with new kernel (this is practicaly the only heavy duty app that runs on that server so no problem with threading amount and I will probably remodel old one too and upgrade kernel). And threading gives me no fact program never stops and is always responsive.

as it concerns threaded sockets I can still send a copy (after friday when debugging will be over, for now test is running smooth for two days in 30 connections). It's merely just inherited components, that make communication very, very easy to code.

m.

-------------------
http://www.email.si