1. To Cense about Signal ()
- Posted by Kayhlan <kayhlan at EARTHLINK.NET>
Nov 15, 2000
-
Last edited Nov 16, 2000
First off, let me start by saying I will name every child I have from this day
forward after you, with
different middle names of course, as it could get really confusing otherwise. .
. .
Now that I've done my schmoozing, there is a comment and a couple of questions
left:
Your suggestions on Send() worked perfectly and I understand the wrapper for
signal() that you wrote. My
question or two about it is, considering my previous example of write(now send),
assuming that the SIGPIPE
would be returned before send() has a chance to return -1, when would you run
the signal()? Is this
something that needs to be run only once, and it will work for the duration or
does it need to be called
before each instance of send()? The other question is, once the Signal() is
caught, and the specified
routine run, do you have any idea if the main program will continue the send()
or does it skip to the next
line in the sending routine?
In other words, If I send() "message" signal() should direct the call_back to
run a simple routine at the
beginning of the message. Does it continue to try to send the message, thus
running signal() for
length("message") times?
Any more help at this point might seem a tad greedy but your message came
literally five minutes after I had
given up all hope and was opening up my many C manuals to begin re-coding my
game yet another time.
Thank you again, Cense, you've been a life saver.
Kayhlan
cense wrote:
> On Tue, 14 Nov 2000, Kayhlan wrote:
> >> Being an avid Euphoria user, but admittedly a very novice C user I actually
> >> have more questions about your questions than I do answers.
>
> Im not C expert myself, infact i was just in your position a little while ago.
>
> >> First, man 2 write when talking about error messages lists EPIPE "fd is
> >> connected to a pipe or socket
> >> whose reading end is closed. When this happens, the writing process will
> >> receive a SIGPIPE signal: if
> >> it catches, blocks or ignores this error, EPIPE is returned."
>
> hehe, now i see that part of the man page, stupid me
>
> >> Questions about this:
> >>
> >> You say errno would be set properly, but how is this passed into Euphoria?
> >> Do I have to make a global integer in Euphoria or is this just not
> >> possible?
>
> Now again, i dont know a whole lot about C like others on this list (Bernie
> Ryan for sure knows his C programming) but i know that errno is a variable
> declared as "extern int errno" in the include <errno.h>
>
> As far as i know there is no way to access this variable from Euphoria other
> than perhaps peeking into the memory where errno is allocated but i do not
> know
> how to do this myself. Give Bernie Ryan or other more highly qualified C guys
> a
> shout about that question
>
> >> As I said, I have never recorded xxx equal to anything but the length of
> >> the data sent.
> >> (Possibly because the time it would return -1 it terminates with the broken
> >> pipe)
>
> I agree with this theory of why you are never getting -1
>
> >> I do use recv() instead of read, however I cannot make Euphoria pass
> >> strings to C so I have been
> >> unable to get send() to work properly.
>
> to get Euphoria to pass a string to a C routine, you need to put your sequence
> (the euphoria string) into memory ala C style. This can be accomplished using
> a
> simple function like this:
>
> function alloc_string( sequence str )
> atom ptr
>
> ptr = allocate( length( str ) + 1 )
> poke( ptr, str & 0 )
>
> return ptr
> end function
>
> A C compliant pointer is returned by alloc_string which can be used in
> wherever
> a "char *" is needed. In your case, the second argument to send( )
>
> send can also accept pointers to any type of data so if you are not sending
> strings, it will work exactly the same.
>
> >> And as far as "catching" the signal, other than poll() (which is not
> >> catching the disconnect all the
> >> time) I have no clue how to go about detecting the disconnection another
> >> way. Is there some function
> >> that would test a socket to see if it is still active?
>
> To "catch" a signal sent to a process, you have to install a new signal
> handler
> by using the function "signal( )". the man 2 signal page has some info on
> signal but its still kinda confusing so i can give you a little extra help on
> that. I have a wrapper for "signal( )" that i *think* works but i have not
> tested it, it goes as follows:
>
> function signal( int signum, int routine )
> atom sig_handler_ptr, ret_ptr
>
> sig_handler_ptr = call_back( routine )
> ret_ptr = c_func( signal_, { signum, sig_handler_ptr } )
>
> if ret_ptr = sig_handler_ptr then
> return 0
> else
> return 1
> end if
> end function
>
> Now for my documentation. signal( ) above takes two arguments, the first is
> the
> signal number you want "catch" (in your case SIGPIPE or 13). The second
> argument is the routine_id of the function that you will be using to handle
> the
> signal when it is recived. You can get the routine_id of any function in
> euphoria by using "routine_id( s )" check the Euphoria reference manual for
> details.
>
> If you need some more help with signal or if you dont understand my
> rambling, mail back once more and i will try to be a little more clear and
> in-depth.
>
> >> thanks very much for your help so far,
>
> No problem, this is what the mailing list is for!
>
> >> Kayhlan
>
> --
> evil, corruption and bad taste
> ^[cense]
2. Re: To Cense about Signal ()
Sorry about the day late response but i was in no shape yesterday to give you
any response even though i did check my mail.
On Wed, 15 Nov 2000, Kayhlan wrote:
>> First off, let me start by saying I will name every child I have from this
>> day forward after you, with
>> different middle names of course, as it could get really confusing otherwise.
>> . . .
>>
>> Now that I've done my schmoozing, there is a comment and a couple of
>> questions left:
hehe, all good
>> Your suggestions on Send() worked perfectly and I understand the wrapper for
>> signal() that you wrote. My
Well actually Jeff Fielding wrote it/ helped me with it and i just *slightly*
modified it for my use, ill pass any credit onto him for it.
>> question or two about it is, considering my previous example of write(now
>> send), assuming that the SIGPIPE
>> would be returned before send() has a chance to return -1, when would you run
>> the signal()? Is this
>> something that needs to be run only once, and it will work for the duration
>> or does it need to be called
>> before each instance of send()?
Well according to the man page for signal, the general answer to both your
questions is, yes. I know that does not help so im going to clearify some
stuff. in C, if you include <signal.h> then yes, you have to call signal
everytime before you make the call to send. if you include <bsd/signal.h> you
do not. Now by default you are using <signal.h> so you would have to make this
call before every call to send( ). As long as you make the call to signal( )
before send( ) gets the SIGPIPE signal you are fine. ( unless a previous call
to send has "used" your last call to signal, then you must call signal again )
>> The other question is, once the Signal() is caught, and the specified
>> routine run, do you have any idea if the main program will continue the
>> send() or does it skip to the next
>> line in the sending routine?
Well that can all depend on what you put in the routine to handle the signal,
this i am not too familiar with, so again ask a C ( and linux ) guru about how
to make an effective routine handler.
>> In other words, If I send() "message" signal() should direct the call_back to
>> run a simple routine at the
>> beginning of the message. Does it continue to try to send the message, thus
>> running signal() for
>> length("message") times?
I do not think this will happen.
>> Any more help at this point might seem a tad greedy but your message came
>> literally five minutes after I had
>> given up all hope and was opening up my many C manuals to begin re-coding my
>> game yet another time.
As long as im not coding your MUD and then you slap your name on it i dont
think your being greedy.
>> Thank you again, Cense, you've been a life saver.
no problemo capitain.
>> Kayhlan
Oh, just one last thing, if you would do me a favor. I am still working on my
socket wrapper and i through away my old code to wrap "poll( )" so i was
wondering if you could send me a little snippet of your code around where you
call poll so that i can easily wrap the mutha?
--
evil, corruption and bad taste
^[cense]
3. Re: To Cense about Signal ()
- Posted by Kayhlan <kayhlan at EARTHLINK.NET>
Nov 17, 2000
-
Last edited Nov 18, 2000
Once again, all your information was right on and true, Cense. Thanks for the
help.
As far as the wrapper for poll() I actually (all credit be to him) lifted it
from Pete Eberlein's Client/Server
program that you can find in the Archive of rapideuphoria.com. At this point,
my poll() is, well, messy. Oh no, it
is a real mess! I think you will find Pete's example to be much clearer than
mine, however I would be more than
happy to paraphrase my messiness in a post if you would like.
Also, I would like to offer you help in any way with any socket or client/server
way that I can. Thanks again, and
if you ever want to see what your assistance has helped to bring about, feel
free to stop by my MUD at orone.com,
port 23. Ask for Draegur, (the big, red guy shouting lots of insults to the
lowly mortals) or Genessa, (the blue
girl trying to soften the blows). <g>
Take care,
Kayhlan
cense wrote:
> Oh, just one last thing, if you would do me a favor. I am still working on my
> socket wrapper and i through away my old code to wrap "poll( )" so i was
> wondering if you could send me a little snippet of your code around where you
> call poll so that i can easily wrap the mutha?
