Re: Chat server impossible with Perl?

makes perl threads more similar to a toy than a tool: the impossibility to share objects, especially if they are of the filehandle kind...

With caveats--mostly surmountable--it is possible to share globs between threads. But it is a bit messy and awkward, which is why I have (mostly) avoided discussing the method publicly.

I think that this is an unecessary restriction of threads::shared that could and should be lifted. At the basic level filehandles are a per process resource and are accessible from every thread. The current restriction is artificially imposed and can be bypassed. What is required is a documented and tested mechanism for doing shared access--rather than the current situation whereby it can only be done using obscure coding tricks.

There are two things that prevent me from attempting to get the retriction lifted. The first is my lack of internals skills. The second is that whatever I develop will only be tried and tested on Win32. Without addressing these two areas, the best I could hope to do is offer suggestions for change which is a lot less likely to get anywhere than a "tested on XX and YY" patch.

All of that said, it is totally possible, and even quite easy to write a simple, complete and efficient chat server using threads. The first thing you have to do is throw away the "fork and exec" approach to the problem, and view it from the perspective of "How do I use threads to listen for new connections whilst maintaining responsiveness to existing ones".

Once you shed the shackles of preconditioned thinking, it becomes relatively easy :)

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Comment on Re: Chat server impossible with Perl?

Replies are listed 'Best First'.
Re^2: Chat server impossible with Perl? by MarkusLaker (Beadle) on Feb 05, 2005 at 00:23 UTC
How do I use threads to listen for new connections whilst maintaining responsiveness to existing ones You may not need threads to do that. Although perlipc and perlfunc don't mention it, you can run `select` on a generic socket, at least on Unix. In more detail: You open perlipc, find the section labelled 'Internet TCP Clients and Servers', and use the recipe to create a generic server socket: `socket(), setsockopt(), bind(), listen()`. You now build a bitmask and go into a `select` loop. (If you've not used `select` before, perlfunc explains how. `select` is a way of sleeping until there's some activity on one or more of any number of connections.) When `select` says there's something ready for your generic socket to read, it means there's an incoming connection attempt: so you `accept` the connection, flip a bit in your bitmask to represent the new connection, and go back to the top of your `select` loop. You're now in an interesting position: `select` will return when you're ready either to accept a new connection or to read data from an existing connection. So, if you can service an incoming packet quickly enough, a single fibre is all you need. That said, I'd be fascinated to know how to share globs between Perl threads. I threw away a day's work earlier this week because Perl told me it couldn't be done and (as this was work time) I decided not to spend time trying to hack it. At the very least, this restriction should be documented in perlthrtut and/or threads::shared. Markus	[reply] [d/l] [select]
Re^3: Chat server impossible with Perl? by BrowserUk (Patriarch) on Feb 05, 2005 at 00:45 UTC
I'd be fascinated to know how to share globs between Perl threads. Supersearch for a thread by me with a title including "threads" and "globs" for my initial experiments in doing this. Basically, you need to pass a "handle" to a glob through a shared variable in such a way that threads::shared doesn't stick it's nose in and reject you. Be warned: The technique I used there has problems. I've a couple of other ways of doing it that I am experimenting with, but I would rather keep them quiet till I've proven to myself that they can be used reliably. Perl threads have an undeservedly bad rep as it is, without me causing more problems sharing speculative ideas without checking them out first. (Which is why I'm not linking to the post in question--If you want to try it, your gonna have to do a little work:) Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply]