From: Michael Jones <mjones@linear.com>
To: Grant Edwards <grant.b.edwards@gmail.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Advice on streams and bsd sockets
Date: Tue, 21 Jan 2014 15:43:00 -0000 [thread overview]
Message-ID: <98E57315-9D90-4364-BE15-EBAF40D08062@linear.com> (raw)
In-Reply-To: <lbm2kd$5if$1@ger.gmane.org>
The lseek simply deals with the read buffer and sets position to 0. I tried to swallow the error, but there is some strange artifact left over that causes telnet to print a ^M. When I tracked that down, it was related telnet failing to negotiate because writes were not working. I did not track down how it broke write. I am guessing that the problem is just that no one expected streams to be used with the networking and it probably needs more work than I have time.
I tried an alternate solution. I used two streams, one for read, and one for write. This even worked well in the case where my telnetd was using the file descriptor to handled telnet configuration and streams were used for lua. As long as lua is flushing, they coexist properly.
But two streams sharing a file descriptor create a new problem. I need to close both streams to release resources because in a telnet environment people log out and log back in. When the streams use the same file descriptor, the second close returns an error and resources are not freed. The error comes from the first close which also closes the file descriptor.
I modified fclose to free resources even when there is an error, but that may not be POSIX behavior or may have side effects.
Does anyone know in general if streams can share a file descriptor in other systems and all be closed properly? If this is the expected behavior, it is probably easier to modify fclose than to solve the seek problem. It is also a more natural solution because lua was already setup for stdin and stdout and two streams match the way the code is structured.
For those interested, my telnetd package with command line support including lua will be available for others to use. It is part of my Cortex A9 work for iMX6 SMP hal. Sooner or later someone will post the link on the ecos site.
Mike
On Jan 21, 2014, at 8:10 AM, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2014-01-21, Michael Jones <mike@proclivis.com> wrote:
>> I am looking for some advice on using streams with sockets. I am using CYGPKG_NET and taking the socket handle and creating a stream with fdopen().
>>
>> A fwrite() eventually arrives in this code:
>>
>> static int
>> bsd_lseek(struct CYG_FILE_TAG *fp, off_t *pos, int whence)
>> {
>> return ESPIPE;
>> }
>>
>> And this causes an error, but a second call to fwrite() works. It
>> always happens when there is a fwrite() immediately after a fread(),
>> as that triggers the seek.
>>
>> I am looking for advice on how to handle this problem.
>
> What I would do is first add a diag_printf() to bsd_lseek() to print
> out the paramters so you can see exactly what sort of seek is being
> attempted. You could add a bit of code to bsd_lseek() to check for
> (and return success for) "noop" operations (e.g. seek to 0 offset from
> current location).
>
>> Of course I could not use streams, but I am working with lua 5.2.3
>> and it is based on streams, and don't want to modify it that much. I
>> also can't turn off buffering, because lua relies on the ability to
>> push bytes back into the stream after reading them.
>>
>> Does anyone have a patch that works around the problem or know of
>> some other way to create a stream that does not rely on seek? In the
>> case where I use it, there is no need for seek anyway. I am using the
>> stream in place of stdin and stdout so that lua can interact with a
>> telnet session.
>
> If the code works OK with stdin/stdout streams, then the lseek() calls
> must not be actually doing anything, right? If that's the case, then
> it should be easy enough to modify the the bsd_lseek() function to do
> the same.
>
> --
> Grant Edwards grant.b.edwards Yow! I haven't been married
> at in over six years, but we
> gmail.com had sexual counseling every
> day from Oral Roberts!!
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
prev parent reply other threads:[~2014-01-21 15:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 6:35 Michael Jones
2014-01-21 15:10 ` [ECOS] " Grant Edwards
2014-01-21 15:43 ` Michael Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98E57315-9D90-4364-BE15-EBAF40D08062@linear.com \
--to=mjones@linear.com \
--cc=ecos-discuss@ecos.sourceware.org \
--cc=grant.b.edwards@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).